Bugzilla Bug 84744

The following list are those modules I've identified in the core perl install
for perl 5.8.6 that we provide ebuilds for. Need to add blocks to ebuilds for
older versions of these modules so that users don't end up with a
deprecated/older module than what the perl core already provides. This list
might not be conclusive, and there may be some includes that aren't valid, but
I think it's right.



Reproducible: Always
Steps to Reproduce:
1.
2.
3.




DB_File.pm = 1.810 
Storable.pm = 2.13
Time::HiRes.pm = 1.65
MIME::QuotedPrint.pm = 3.03
MIME::Base64.pm = 3.05
Memoize.pm = 1.01
Attribute::Handlers.pm = 0.78_01
ExtUtils::MakeMaker.pm = 6.17
File::Spec.pm = 3.01
File::Temp.pm = 0.14
Filter::Simple.pm = 0.78
Getopt::Long.pm        =  2.34
Locale::Maketext.pm = 1.09
Math::BigInt.pm = 1.73
Math::BigRat.pm = 0.13
Math::Complex.pm = 1.34
Net::Cmd.pm = 2.26
Net::Config.pm = 1.10 
Net::Domain.pm = 2.19 
Net::FTP.pm = 2.75
Net::hostent.pm = 1.01
Net::netent.pm = 1.00
Net::Netrc.pm = 2.12 
Net::NNTP.pm = 2.23
Net::Ping.pm = 2.31
Net::POP3.pm = 2.28
Net::protoent.pm = 1.00
Net::servent.pm = 1.01
Net::SMTP.pm = 2.29
Net::Time.pm = 2.10
Net::FTP::A.pm = 1.16
Net::FTP::dataconn.pm = 0.11
Net::FTP::E.pm = 0.01
Net::FTP::I.pm = 1.12 
Net::FTP::L.pm = 0.01
Term::ANSIColor.pm = 1.08
Term::ReadLine.pm = 1.01
Test::Harness.pm = 2.42
Test::Simple.pm = 0.47
Text::Balanced.pm = 1.95
Text::Tabs.pm = 98.112801
Text::Wrap.pm = 2001.09292
List::Util.pm    = 1.14
Scalar::Util.pm    = 1.14

For anyone else peaking in, this bug is for me to use as a baseline for
tracking these fixes.

A list for 5.8.5 thanks to will in the about to be dup'd bug

dev-perl/Attribute-Handlers-0.78
dev-perl/CGI-3.05
dev-perl/Data-Dumper-2.121
dev-perl/Digest-MD5-2.33
dev-perl/ExtUtils-MakeMaker-6.17
dev-perl/File-Spec-0.87
dev-perl/File-Temp-0.14
dev-perl/Math-BigInt-1.70
dev-perl/Memoize-1.01
dev-perl/MIME-Base64-3.01
dev-perl/Safe-2.11
dev-perl/Storable-2.13
dev-perl/Term-ANSIColor-1.08
dev-perl/Test-Harness-2.42
dev-perl/Test-Simple-0.47
dev-perl/Text-Balanced-1.95
dev-perl/Time-Local-1.10
dev-perl/Time-HiRes-1.59

*** Bug 84769 has been marked as a duplicate of this bug. ***

Changing topic since this is branching to include 5.8.5. My current thinking
process was to:

*) Ensure we meet at least (of course, exceeding good too) the same ebuild
module versions in relationship to what is in the core install(s)
*) Brew coffee then hunker down and go through and mark all ebuilds that dep
one of the listed ebuilds as (ebuild || >= perl-version) so that one of the two
is satisfied
*) Make sure I haven't broken the universe (I forsee dep bugs to the individual
maintainers to cover that)
*) At that point, I'm actually aiming to unmask 5.8.6 for the x86 and (if weeve
doesn't shoot me) sparc

Ultimately, I'd like to get a process in place so that when we get to adding
5.9.1(+), we have a methodology to avoid this snafu that festered naturally
over time.

Hey Michael, I appreciate the effort.  Thank you.  If I could ask one more
thing, since you're going through a large number of ebuilds could you change
their SRC_URI to:
   mirror://cpan/
where appropriate.

No fears, I always transition to mirrors for the SRC_URI.

And to clarify my thoughts on magic bullet 2, though I'm even more sleep deprived now...my thought is to block perl's with newer versions in the older ebuilds, ie if module foo is 3.0 in perl-core for 5.8.6, blocking perl-5.8.6 from foo <3.0 in the ebuilds, as well as making sure everything core related is up to date, and hopefully doing the ( ebuild || perl-version) thingie. And yeah, I know this isn't a small undertaking, but what else was I going to do with my free time? :)

I know the painful/inacurate/kludgy method I used to generate my list of modules - did you have a smarter, more concise, egads maybe already done for us method of getting modules/versions for perl versions? (wishful thinking, just trying to avoid the work related to that grep/sed/awk/grep sequence I used)

Sorry to make this a semi-blog - hopefully this will be my last fluff post, but
I realized on the drive in this morning that it would be a bad idea (TM) to go
through and mark ebuilds as (foo||perl-version). Scenario one is that a lot of
apps just dep foo - not foo-version, so where to draw the line on versions?
Second scenario, and this is the one that was my thinking cap realization, is
that if we have foo-2, and a package deps on it or greater, and perl-version
comes with foo-3, we don't want to do the (foo-2||perl-version) because what if
we need to bump the ebuild for foo-3 due to a security/functionality bug? Of we
use the || syntax none of those people who qualified with mere perl-versions
would get it. But if instead I limit the scope of this to just making sure we
have foo-2 and foo-3 or greater in the tree, and that foo-2 blocks and
perl-version that comes with a greater version, we are all set. Yes, there will
be cases where are providing an ebuild for the same version as a vanilla perl
install, but at least we would still have the ability to bump their foo's if
need be later.

Yeah, I swear, last fluff post :)

I agree with you on your whole deps scenarios.  That's why I like using
/etc/portage/profile/package.provided to tell portage what versions of the
modules are already installed on my system.  That way, if an older version of a
module was installed, it would be uninstalled via emerge depclean.  And if a
newer version comes out sometime in the future, it will be installed.

Is there a way for one ebuild to say it is providing another ebuild, and hence,
it's already installed.  It looks like the only thing an ebuild can provide is
a virtual.

Anyway, I got my list by grep'ing /var/db/pkg/dev-lang/perl-5.8.5-r4/CONTENTS
and manually comparing that against -- ls /usr/portage/dev-perl

Will

I've removed the dep for Attributes-Handlers from the two perl modules that
dep'd it, so that can be removed from the tally. I think I am going to setup a
page to track versions for 5.8.5 and 5.8.6, mark those with ebuilds, and then
mark those that are done, so that I can keep better track of where I stand on
this. Attribute-Handlers is no longer maintained external to the perl-core
install, at least not at this time, and for perl 5.8.{4,5,6) it has been at
0.78_01, where we only provided an ebuild for 0.78. I've created a patch and
applied it to the tree to manually bump any installs of the module to the
current release, but I'd like to slate this ebuild for removal eventually.

http://www.datanode.net/articles/perl-map.html

Slow, painful, and manual, so it only has the modules I've worked with so far. Will see if I can automate this somewhat shortly, but at least for now it's a start.

http://www.datanode.net/articles/perl-map.html is updated with the ebuild vs
perl core module version install. There are a few false positives, a few
ebuilds that can be removed from the tree since I've taken care of the modules
that inacurately dep'd them, like Attribute-Handlers and Data-Dumper, but all
in all pretty comprehensive. Could use some more massaging for output
readability, in particular in regards to the arch's, but its a start (and I've
wasted a bit of time on getting it here already).

http://www.datanode.net/articles/perl-core.html contains a list of the modules
installed by each core install.

Just so there aren't any fears, this bug is still very alive, just been a
little busy lately (probably the subject of another boring planet.gentoo post).
Thanks for your patience,

Mike

OK, the only ebuild I haven't submitted an arch bug on at this point is
File-Spec, but that's because I need to figure out the best way to handle it
(not only is it a major version change, but the upstream package has changed
names)

Michael, the two files you linked are unfortunately 404.

sorry, old links, /arcticles became /gentoo-perl/ (decision i made for some
reason or other...). will post real links later :)

Hey Michael, props on your g-cpan upgrade.  It rocks!

I ran g-cpan -i SQL::Translator and it wanted to install the modules
perl-gcpan/IO for IO::Dir, perl-gcpan/PathTools for File::Spec and
perl-gcpan/Pod-Parser for Pod::Usage.  All of those are provided in perl-core.

The PathTools package is interesting.  From the README in CPAN, it looks like
File::Spec and Cwd have been merged into PathTools.  My guess is that is what
the ebuild should be going forward.

Thanks, Will

(In reply to comment #2)
> A list for 5.8.5 thanks to will in the about to be dup'd bug
> 
> dev-perl/Attribute-Handlers-0.78
> dev-perl/CGI-3.05
> dev-perl/Data-Dumper-2.121
> dev-perl/Digest-MD5-2.33
> dev-perl/ExtUtils-MakeMaker-6.17
> dev-perl/File-Spec-0.87
> dev-perl/File-Temp-0.14
> dev-perl/Math-BigInt-1.70
> dev-perl/Memoize-1.01
> dev-perl/MIME-Base64-3.01
> dev-perl/Safe-2.11
> dev-perl/Storable-2.13
> dev-perl/Term-ANSIColor-1.08
> dev-perl/Test-Harness-2.42
> dev-perl/Test-Simple-0.47
> dev-perl/Text-Balanced-1.95
> dev-perl/Time-Local-1.10
> dev-perl/Time-HiRes-1.59

Pardon my ignorance, but is the "perl-core vs dev-perl" conflict why I'm now
seeing this after an "emerge sync && emerge -uDpv world"?

Calculating world dependencies -
emerge: there are no ebuilds to satisfy "dev-perl/Test-Simple".


!!! Problem with ebuild dev-perl/Term-Screen-1.02
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.

I have perl-core/Test-Simple-0.54 on the system.

If so, should I just hang loose until you folks sort it all out?
Thanks for all your hard work, BTW!
Bill

That's in his overlay btw - part of the reason the new g-cpan uses a unique 
overlay dir 

It seems that digest-base, conflicts with the new perl-5.8.7. I have turned the
packet collision on and it has detected /usr/share/man/man3/Digest::file.3pm.gz
as not owned by the perl package. I assume it is added to the new version of perl.

(In reply to comment #19)
> It seems that digest-base, conflicts with the new perl-5.8.7. I have turned the
> packet collision on and it has detected /usr/share/man/man3/Digest::file.3pm.gz
> as not owned by the perl package. I assume it is added to the new version of perl.

Yeah, the perl-core list needs to be updated (and 5.9.* will add even more).

At this time, there is no way to avoid the collisions btw - its a conflict of
man pages 99.99% of the time (except maybe if we don't include man pages by
default with the perl install? ick. then again - who needs man when you have
perldoc...?)

I agree with removing the man-pages (or adding them as a different ebuild),
because I have even more collisions nowadays - Test-Harness, qdbm and gaim. 
I don't know where to report them (I think here is the right place, but the bug
seems a little bit inactive in recent times).

(In reply to comment #21)
> I agree with removing the man-pages (or adding them as a different ebuild),
> because I have even more collisions nowadays - Test-Harness, qdbm and gaim. 
> I don't know where to report them (I think here is the right place, but the bug
> seems a little bit inactive in recent times).

bug 71659

and this bug is really about ebuilds vs. core installs for versions, not man
pages :) and after a final sweep, should be closeable at last

this bug can be wrapped up until the next stabilization. this bug also has
zilch
to do with bug 80184, so i'm removing that block. that bug is about whether pod
parser should be a dep of spamassassin - this bug was about making sure that
the
same version of a module that we have an ebuild for was stable in match of the
version that came with the stable perls, not about conflicts of collisions,
etc.