develooper Front page | perl.perl5.porters | Postings from March 2021

Re: on changing perl's behavior

Thread Previous | Thread Next
Dominic Hargreaves
March 29, 2021 23:45
Re: on changing perl's behavior
Message ID:
On Mon, Mar 29, 2021 at 09:48:06AM -0500, B. Estrade wrote:
> In additional to fostering (at a high level) tooling around distributing
> Perl applications, has anyone taken a serious look at what's going on with
> perl and linux/BSD distros?
> * OpenBSD is the only one that keeps it base (that should tell you something
> - good)
> * FreeBSD took it out of base YEARS ago
> * FreeBSD is the only freenix that supports more than one version of perl (4
> at least count) and has a means to have them all installed at once; even if
> the /usr/local/bin/perl is symliked to only one at a time (they do the same
> for python2,3 and ruby, etc)
> * pkgsrc (NetBSD) supports a LARGE number of systems, yet provides only one
> version of Perl (fairly up to day)
> * Ubuntu - omg, the way it breaks up perl-doc, libperl-dev, etc, etc - not
> good for Perl at all
> * RH/Centos - idk even know any more, I think it breaks up the perl stuff
> like Ubuntu but I have not checked
> This is definitely going into the Perl advocacy realm, who among us is
> "officially" in charge of nagging Canonical about the way it breaks up Perl?
> Who was on the horn with FBSF when they ripped perl out of their base?  Is
> anyone working with Strawberry Perl or wx-widgets? You want Perl apps on
> Windows? There's your core team, and one of them might even be economically
> viable.

I'm not sure how this relates to the topic to hand, but... I'm one of the
current co-maintainers of perl in Debian (and by extension Ubuntu). We
enjoy a fruitful relation with the upstream perl community with the
occasional upstream contribution and many more downstream contributions
arising from issues we face (including helping to support older perls
in our stable releases). I don't believe we have ever been nagged about
the way that perl is split into different binary packages in Debian
in the decade since I got involved from anyone involved in upstream
perl development.

Those splits are all there to support perl being smoothly installed as
part of the base system (where there are strict size constraints, and
strict "this must always work even the middle of upgrade" constraints)
as well as to support perl running on a dozen different architectures,
and to support various upgrade paths for XS modules. All if which is
mostly invisible to the regular user who just wants to apt-get install perl
and have it work.

But you haven't explained what you find so offensive about this
situation. Why is this not good for Perl?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About