| Summary: | perl is not compliant with FEATURES="collision-protect" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexander Skwar <askwar> |
| Component: | Current packages | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | betelgeuse, bsd+disabled, bugs, casta, chris-ml-gentoo-bugzilla, damien.thebault, david+gentoo.org, ehmsen, gentoo.org, hanno, jakub, ka0ttic, lars, lukenshiro, mal, mark, moixa, sanchan, sascha-gentoo-bugzilla, solomarv, spock |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 89890 | ||
| Bug Blocks: | |||
|
Description
Alexander Skwar
2004-11-18 05:04:01 UTC
*** Bug 71868 has been marked as a duplicate of this bug. *** *** Bug 73392 has been marked as a duplicate of this bug. *** *** Bug 73394 has been marked as a duplicate of this bug. *** *** Bug 73396 has been marked as a duplicate of this bug. *** *** Bug 73448 has been marked as a duplicate of this bug. *** *** Bug 77648 has been marked as a duplicate of this bug. *** *** Bug 78303 has been marked as a duplicate of this bug. *** *** Bug 79053 has been marked as a duplicate of this bug. *** *** Bug 79366 has been marked as a duplicate of this bug. *** Now that I've gathered all ye bugs together... Perl is not, and I don't see where it ever will be, compliant with collision-protect. And before that causes an uproar.... * We provide ebuilds that suppliment and update modules that were installed by the core perl package. This means that files will be updated that were originally owned by dev-lang/perl. This is the price you pay for being secure, up to date, and able to install packages that depend on newer versions of modules than came with the original perl core you are working with. * Some module authors include "stubs" from other modules they maintain which conflict under collision-protect. Carp-clan is an example of this - there is the ebuild for the module, which is the full puppy, but the author also includes a bare stub of it in his other modules for use. But the man pages, pm files, etc., are all the same (for obvious reasons regarding @INC). I'm open to suggestions. For the time being I recommend you remove collision protection for your perl needs. It is a good thing to have, but in the case of perl it's going to be tough. The only thought I can come up with is sometime after we split up dev-perl into parts, we can PDEPEND the core modules that can be updated. Even then, though, there will be stragglers that do still collide. *** Bug 89825 has been marked as a duplicate of this bug. *** So portage needs an /etc/portage/package.features, in which we can put: dev-lang/perl -collision-protect or: dev-perl/PodParser -collision-protect And in the long term, portage could maintain a /usr/portage/profiles/package.features Comments? Mal, that would be nice - but that's a portage "bug"/feature request (outside this bug) Well, yes, that might be really useful - It would, however, be much more useful, if everything could be installed with +collision-protect and if the ebuild could specify which files are okay to be overwritten. I filed bug #89890 to track what MAL suggested in comment #12. The sad thing is that it should only be the man pages that are in conflict here (we install the modules in vendor, core install is usually either in straight out PERL_VERSION or site_perl), but at the same time we can't ignore the new man pages because they may contain changes/updates over the core install. On the upside, I have a freaky idea whenever we get versioned virtuals going that we could prove virtual/perl-pod-parser-1.2.8 in both dev-lang/perl and dev-perl/podparser - usually people only hit this "bug" when they're pulling in a dep, but if the virtual sees the dep being filled by dev-lang/perl already then we could at least avoid a portion of the collision protect bugs. *** Bug 90740 has been marked as a duplicate of this bug. *** *** Bug 87771 has been marked as a duplicate of this bug. *** *** Bug 91713 has been marked as a duplicate of this bug. *** *** Bug 91714 has been marked as a duplicate of this bug. *** *** Bug 91715 has been marked as a duplicate of this bug. *** *** Bug 91716 has been marked as a duplicate of this bug. *** I I´m changing the summary of this bug to something more appropriate. *** Bug 92422 has been marked as a duplicate of this bug. *** *** Bug 89869 has been marked as a duplicate of this bug. *** *** Bug 92847 has been marked as a duplicate of this bug. *** *** Bug 97453 has been marked as a duplicate of this bug. *** FEATURES="" emerge -u perl doesn't work for turning off collision protection. Re comment #28: Use FEATURES="-collision-protect" to disable collision-protection. *** Bug 102105 has been marked as a duplicate of this bug. *** Mass re-assign. *** Bug 106914 has been marked as a duplicate of this bug. *** guys... perl module ebuilds in gentoo are a real mess. and i mean MESS. differentiating systems between perl built with 'minimal' (+ all perl modules used by different applications) and 'full' perl conflicting with anything else is a real failure of gentoo :| i am sure this is very annoying for us, regular gentoo users ... is there a lack of will to solve it or is it just matter of solving conflicts between gentoo guys responsible for perl ebuilds??? (In reply to comment #33) > guys... perl module ebuilds in gentoo are a real mess. and i mean MESS. > > differentiating systems between perl built with 'minimal' (+ all perl modules > used by different applications) and 'full' perl conflicting with anything else > is a real failure of gentoo :| I've really missed how is this related to collision-protect; the reasons why perl is not collision-protect compliant are pretty much explained above. > is there a lack of will to solve it or is it just matter of solving conflicts > between gentoo guys responsible for perl ebuilds??? Ditto... So, please, don't clutter this bug w/ irrelevant comments. Thanks. P.S. perl w/ minimal use flag is *not* suitable for general usage (explained many times in many other bugs). Now, please keep on topic. (In reply to comment #16) > The sad thing is that it should only be the man pages that are in conflict here (we install the modules in vendor, core install is usually either in straight out PERL_VERSION or site_perl), but at the same time we can't ignore the new man pages because they may contain changes/updates over the core install. I experienced the problem now with perl-core/Test-Harness-2.42. The modules are installed fine into vendor, which means for me that perl _is_ compliant or at least can be made compliant with collision-protect. It is just, that we need to install the man pages of modules that "overlay" modules, which are included in perl, into a directory where they are not overwriting the man pages shipped with perl, but overriding them. I placed a file in /etc/env.d which is used before 00basic (ugly!) # echo MANPATH="/usr/lib/perl5/vendor_perl/5.8.6/man" > /etc/env.d/000perl-5.8.6 # env-update >>> Regenerating /etc/ld.so.cache... # . /etc/profile Changed the perl-modules.eclass --- /usr/portage/eclass/perl-module.eclass.old 2005-11-05 07:58:36.000000000 +0100 +++ /usr/portage/eclass/perl-module.eclass 2005-11-05 07:58:59.000000000 +0100 @@ -107,7 +107,10 @@ else einfo "Using ExtUtils::MakeMaker" perl Makefile.PL ${myconf} \ - PREFIX=/usr INSTALLDIRS=vendor DESTDIR=${D} + PREFIX=/usr INSTALLDIRS=vendor \ + INSTALLVENDORMAN1DIR=/usr/lib/perl5/vendor_perl/5.8.6/man/man1 \ + INSTALLVENDORMAN3DIR=/usr/lib/perl5/vendor_perl/5.8.6/man/man3 \ + DESTDIR=${D} fi } There is however a case where Build.PL is used instead of Makefile.PL. Not needed for Test-Harness and therefore not dealt with at the moment. Now when emergeing Test-Harness, the man pages are installed fine into my new vendor man page directories, without collisions and 'man Test::Harness' even shows the new version. To be honest the next was /usr/bin/prove to collide. I renamed it, but some part of my mind already started thinking. I did the emerge again. It worked without collision. "man Test::Harness" shows the same version as before. hmmm. I edited the new file - voila - it really shows the new file. hmmm. I started to feel stupid. The exactly same version (2.42) is already provided by perl, which leads me to the conclusion, that this versioned virtuals are definitely nice too have - at least from this point of view. Please dont judge me by this - I just got up and I had no coffee yet ;) Please consider this in no way to be compliant with any standards, but just as a proove of concept, which might help to find a solution. > On the upside, I have a freaky idea whenever we get versioned virtuals going that we could prove virtual/perl-pod-parser-1.2.8 in both dev-lang/perl and dev-perl/podparser - usually people only hit this "bug" when they're pulling in a dep, but if the virtual sees the dep being filled by dev-lang/perl already then we could at least avoid a portion of the collision protect bugs. That would be really nice to have - see above. *** Bug 111673 has been marked as a duplicate of this bug. *** Mass re-assign. *** Bug 112345 has been marked as a duplicate of this bug. *** *** Bug 113400 has been marked as a duplicate of this bug. *** This should be now resolved for a good 99% of all cases. The perl-module eclass has been broken into a perl-app and perl-module eclass (perl-app inheriting its bulk from perl-module). Perl modules will no longer generate man3 pages in addition to the standard pod docs available in perldoc. The net result of this is that the file collisions that folks were experiencing should be eliminated now (the collisions were for the most part a conflict between the man3 pages of dev-lang/perl and dev-perl||perl-core ebuilds). Since this was added to the eclass directory last night, safe to say it's propagated outwards, so I'm going to go ahead and close this monster bug. I just hit this bug with perl-5.8.7-r3 and Test-Harness-2.42. When emerging Test-Harness it collides on: existing file /usr/bin/prove is not owned by this package existing file /usr/share/man/man1/prove.1.gz is not owned by this package Anyone can tell me what I should do about that? And which version of prove should be used generally? It seems it's not fully fixed, there's still a collision between dev-lang/perl-5.8.7-r3 and perl-core/digest-base-1.10: >>> Completed installing perl-5.8.7-r3 into /var/tmp/portage/perl-5.8.7-r3/image/ * checking 2638 files for package collisions existing file /usr/share/man/man3/Digest::file.3pm.gz is not owned by this package 1000 files checked ... 2000 files checked ... * spent 1.67967796326 seconds checking for file collisions * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org package dev-lang/perl-5.8.7-r3 NOT merged No package files given... Grabbing a set. root@caravan:~# equery belongs /usr/share/man/man3/Digest::file.3pm.gz [ Searching for file(s) /usr/share/man/man3/Digest::file.3pm.gz in *... ] perl-core/digest-base-1.10 (/usr/share/man/man3/Digest::file.3pm.gz) root@caravan:~# Shall I file a new bug report for that occurence or will it be handled in this report? (In reply to comment #42) > It seems it's not fully fixed, there's still a collision between > dev-lang/perl-5.8.7-r3 and perl-core/digest-base-1.10: > Shall I file a new bug report for that occurence or will it be handled in this > report? No. >=1.13 is fixed, 1.10 will never be fixed. |
