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.
