Class::ISA CPAN install destination

--Apple-Mail-35--746224174
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

There seems to be a conflict in Install location between CPAN and core perl for Class::ISA.

looking at the make file, it's installing to site if perl > 5.11:
'INSTALLDIRS' => ((($] >= 5.007003) && ($] < 5.011)) ? 'perl' : 'site'),
I also note that Porting/Maintainers.PL has this module labeled as DEPRECATED. So if this is the reason CPAN is installing the module into site, I'm cool with that, but shouldn't core also install the module to the same place so we don't have 2 copies of the module if cpan ever does an upgrade of the module?

Alternatively what seems more appropriate is to change INSTALLDIRS to do $] < 5.013 if that's where we plan to remove it as a core module.

Thanks,
Todd
--Apple-Mail-35--746224174--

No, this is working exactly as designed.

It means that the CPAN distribution and the core distribution can have byte
for byte identical files, but the core (well deprecate.pm) can determine
whether one is loading the version supplied by core, or one has installed
from CPAN.

Nicholas Clark

That's a little confusing. So the second a deprecated module is upgraded via CPAN, the deprecation message goes away?

Todd=

YES.

Because the "deprecation" (somewhat misnamed) is that it's to be removed from
*core*. Not, necessarily, that it's not something you should stop using.

The point is that the module will become CPAN only, so you should install it
from CPAN, and if your CPAN modules depends on it, you should add it to
your explicit dependency list.

Nicholas Clark

Correct. What's deprecated is the module's inclusion in core. Not the
module itself.

> Todd

--

What's the deprecation message? Maybe it could be clearer?

David

$>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.

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.

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.

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

Todd

Version numbers must be monotonically increasing or else everything will
come to a screeching halt.  It should be the CPAN maintainer's duty to 
release a new package with a bumped $VERSION before or at the very
latest shortly after the core release for any modules that have been
pulled out of the core.  Even if the only thing that changes is the 
README explaining that this module is no longer in the core...

John

It seems unfair to break things on people with no warning.

The intent was specifically to get third party users of the module to update
their systems (be it Makefile.PLs or in house systems) to explicitly depend
on the module from CPAN.

Until now, there has been a not unreasonable assumption that modules only
enter the core, never leave, hence people do not (generally) have dependencies
on core modules.

So just yanking things from core will break things *without warning*.

> 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.

We had not considered distributions.

The most logical thing seems to be to decouple the modules from the core perl
RPM.

> 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

No. The design is to allow the *same* version number.
This is not changing.

Nicholas Clark

On Feb 8, 2010, at 10:55 AM, Todd Rinaldo wrote:

> $>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.

That's pretty unambiguous.

Best,

David

Better to release 0.37 on CPAN then.

Best,

David

Yep it'll have to be decoupled in the packaging. I guess the question is how to get the word out to any package maintainers who might be considering a perl 5.12 package so they know. If any packagers don't get this right, it could end up being an annoying image problem for perl with end users getting warning messages they can't do anything short of turning off warnings.

I was almost going to suggest some sort of Makefile change to simplify things for the packagers like:

make install_nodeprecations DESTDIR=/tmp/perl512

Which would not include deprecated modules. This would allow p5p to guide distributions on what files are appropriate for a packaged core perl dist.

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

On 8 February 2010 19:55, Todd Rinaldo <toddr@cpanel.net> wrote:
> $>perl.5.11 -W -MClass::ISA -e ''
> Class::ISA will be removed from the Perl core distribution in the next ma=
jor release. Please install it from CPAN. It is being used at -e, line 0.
>
> So I guess the goal here is to make a little noise so people making distr=
ibutions and/or packaging CPAN modules will know they need to update their =
distribution dependency tree and/or Makefile.PL to reference the new depend=
ency since taking core for granted is no longer safe.
>
> 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 co=
re 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 s=
eparately.
>
> If I don't do so, it just makes annoying noise to the user who can't do a=
nything about the packager's (me) original decision to not remove Class::IS=
A 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.
>

The warning is also aimed at people who maintain themselves their perl
installations.

It's also right that it's going to annoy users who install everything
via a packaging system through admins. We could provide a global
switch off for that warning, or rely on heuristics (that will be
wrong, but not always.) Like, disabling the warning if
$Config{vendorlib} is defined. (at Configure time)