Steffen Mueller (smu...@cpan.org)

Hi Jan, hi all,

Jan Dubois wrote:
> But anyways, I still don't see why any of the uppercase words are included
> in this new restriction. perldata.pod kind of implies that uppercase
> words are never "reserved words":
>
> | Using uppercase filehandles also improves readability and protects
> | you from conflict with future reserved words.
>
> Granted, it only says "filehandles", but in the previous paragraph it says:
>
> | "reserved" words aren't in fact reserved with respect to variable
> | names. They are reserved with respect to labels and filehandles,
> | however, which don't have an initial special character.

perlsub in 5.10.0 has this to say on a related topic:
Subroutines whose names are in all upper case are reserved to the Perl
core...


Steffen

Hi Damon,

Damon Atkins wrote:
> # New Ticket Created by  Damon Atkins 
> # Please include the string:  [perl #72892]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=72892 >
>
>
> Perl should support PERLmmnnLIB e.g. PERL0510LIB
> PERL5LIB does not cut it, as different versions of Perl 5 on the same
> system are not compatible. PERL5LIB needs to be set or unset to use
> other versions of perl5
>
> If PERLmmnnLIB is set PERL5LIB & PERLLIB should be ignored
>
> There should also be a perl flag to ignore PERL5LIB etc e.g. perl -I-

I'm sorry, but I'd vote against this proposal. It's equally possible to
have two incompatible installations of Perl (like 64-bit vs. 32-bit or
threaded vs. unthreaded) that carry the same version number.

What you are proposing *should* be solved by the layout of the
directories within the top directory that PERL5LIB points to.

Best regards,
Steffen

Hi Todd, hi David,

Todd Rinaldo wrote:
> On Feb 8, 2010, at 11:04 AM, David E. Wheeler wrote:
>
>> On Feb 8, 2010, at 8:15 AM, jesse wrote:
>>
>>>> That's a little confusing. So the second a deprecated module is
>>>> upgraded via CPAN, the deprecation message goes away?
>>> Correct. What's deprecated is the module's inclusion in core. Not
>>> the module itself.
>> What's the deprecation message? Maybe it could be clearer?

> $>perl.5.11 -W -MClass::ISA -e '' Class::ISA will be removed from the
> Perl core distribution in the next major release. Please install it
> from CPAN. It is being used at -e, line 0.

I think we all agree that's plenty clear, thanks for posting it.

> So I guess the goal here is to make a little noise so people making
> distributions and/or packaging CPAN modules will know they need to
> update their distribution dependency tree and/or Makefile.PL to
> reference the new dependency since taking core for granted is no
> longer safe.

It was the only solution anybody could think of to get rid of old crap
(and stuff that simply doesn't have to be core) and at the same time
provide for the self-imposed deprecation period of such changes. I think
the perl5-porters have a good track record of not simply breaking
compatibility like other languages that start with P. Or R.

> I'm guessing there's an old thread on this topic and I'll grant it's
> too late to change anything for 5.12.0, but IMHO I don't follow what
> the major problem would have been be with just yanking the deprecated
> modules from core and letting all of the new distributions fix their
> dependency trees. As it is now, I have to write code when packaging
> perl via RPM to pull it out of core after the make install so I can
> have the ability later package it separately.
>
> If I don't do so, it just makes annoying noise to the user who can't
> do anything about the packager's (me) original decision to not remove
> Class::ISA from the core RPM. In my case, I'm dealing with RPM, but
> the issue should be identical in Debian and maybe BSD packaging
> design.

This is indeed unfortunate. Maybe it would be possible to include that
bit of code in core (can't be *that* much nor *that* hard) and have a
build option to exclude the deprecated stuff? Then you'd "just" have to
force installation of the now de-cored packages separately. Some form of
virtual-package system should allow for this.

Of course, we're in 5.12 code freeze, so you'd have to be extra nice to
Jesse to get such a tool in before.

> If I could recommend anything for the short term, it would be to
> artificially lower the version number on these deprecated modules in
> core to below CPAN levels so that my first 'cpan -u' (upgrade) makes
> this issue go away. Right now, Class::ISA in core and CPAN are both
> 0.36

As John already pointed out, it must be the other way around. I'm the
sucker for Class::ISA.

Best regards,
Steffen

Hi Merijn,

H.Merijn Brand wrote:
> I did leave a comment after signing in with my OpenID, but it didn't
> show up. Are those moderated?

yep!

Best regards,
Steffen

Dear porters,

since I haven't seen any other mention of it on the list, let me point
you to the "Grant Proposal: Fixing Perl5 Core Bugs" on the Perl
Foundation news site. In a nutshell, Dave Mitchell is willing to work
half-time on fixing core bugs.

The proposal puts it better than I could, so please head over to
http://news.perlfoundation.org/2010/02/grant_proposal_fixing_perl5_co.html
for reviewing and comments.

Best regards,
Steffen

PS: I think posting comments on the grant proposal site is better than
starting a thread here. This is just a heads up!