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

Re: on changing perl's behavior

Thread Previous | Thread Next
From:
B. Estrade
Date:
March 30, 2021 00:16
Subject:
Re: on changing perl's behavior
Message ID:
4b9ab08b-9956-c707-2349-0a5272381a3e@cpanel.net


On 3/29/21 7:11 PM, B. Estrade wrote:
> 
> 
> On 3/29/21 6:16 PM, Dominic Hargreaves wrote:
>> 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?
> 
> I suppose this is fair given I broached the subject. I don't want to 
> distract from the larger topic at hand. Although I must admit I am 
> rather mentally exhausted from my latest spate of emails. :)
> 
> In this specific case, this happens to me, every time:
> 
> 1. docker run -it ubuntu sh
> 
> [note: just checked /usr/bin/perl is there for both ubuntu:latest, 
> debian:latest, and debian:stretch-slim 'out of box'; perldoc is not. 
> alpine (just as another example requires the 'apk add perl' to start; 
> but perldoc is there as expected after `perl` is installed; anyway...]
> 
> 2. /me starts coding, oops! how do I use Getopts::Long again?
> 3. perldoc Getopts::Long
> 4. ubuntu: "boooomp! wrong gotta install perl-doc package" (how I take 
> it, not what it actually says)
> 5. /me (head hits desk), whimpers something about why is so
> 
> But that's me. My goal is not to change your mind. It was just an 
> example asking if anyone tracks these things - that I added a personal 
> comment was actually out of line and wouldn't be part of any type of 
> tracking document I would expect to see. So, apologies if I caused 
> confusion.
> 
> That said, I would love to see some sort of PSC steering document that 
> simply tracked how linux distros, BSD, etc provided perl (minus personal 
> comments) with a mind towards ensuring it be distributed as widely and 
> completely as possible.
> 
> Thank you for providing me an opportunity to explain. And thank you for 
> your hard work, don't think I don't appreciate it.

Oh! And I did forgot one other thing I use perldoc for - a lot of times 
I need to take a look at module source, and I find using `perldoc -l 
Module::Name` to give me the /path/to/Module/Name.pm (or at least .pod) 
extremely helpful. So there you go, that's about as completely as I can 
address the issue you raised.

Brett

> 
> Cheers,
> Brett
> 
>>
>> Dominic
>>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About