Bug #41618 for CPANPLUS-Dist-Gentoo: Build Dependancies can become Unresolvable due to Name Confusion

Wed Dec 10 23:50:27 2008 http://oid.fox.geek.nz/kent.fredric - Ticket created

Subject:

Build Dependancies can become Unresolvable due to Name Confusion

I was testing 0.04 by using it to generate its own ebuild, however, this arose a sequential problem. 1. The Generated DEPENDS list is as follows, of which none exist: DEPEND="dev-lang/perl || ( perl-core/CPANPLUS dev-perl/CPANPLUS perl-gcpan/CPANPLUS perl-gcpanp/CPANPLUS ) || ( perl-core/File-Path dev-perl/File-Path perl-gcpan/File-Path perl-gcpanp/File-Path ) || ( perl-core/PathTools dev-perl/PathTools perl-gcpan/PathTools perl-gcpanp/PathTools ) || ( perl-core/IPC-Cmd dev-perl/IPC-Cmd perl-gcpan/IPC-Cmd perl-gcpanp/IPC-Cmd )" So Naturally, one decides to recursively generate the dependancies to satisfy the condition. ( Its not needed for this ebuild directly, because its already installing fine with only 'DEPEND=""', but for other ebuilds ? ) Now the first invocation to generate CPANPLUS resulted in the following: [ERROR] 256 -- aborting [ERROR] Error(s) in metadata for 'perl-gcpanp/CPANPLUS-0.84': <snip> invalid atom: '>=perl-core/IPC-Cmd-0.40_1' [ERROR] Unable to create a new distribution object for 'CPANPLUS' -- cannot continue Which is, as it says, invalid. Generating and installing IPC::Cmd, and then regenerating CPANPLUS, made it emit a valid atom ( Without Installing, it continues to fail). ( I know its already in core, but this is still permitted behavior ) Eventually, following the dependency branch, you end up with this. ( Run through s/_/ /g to make it readable ) Key: * Generated ** Generated, and all deps are already shown elsewhere on this graph + Available in Gentoo, not traversed @ Available in overlay, not traversed ! Not Available, Cant be generated. (-) cant be installed because of file collision with perl (+) like -, but there exists a virtual to circumvent this ( virtual/perl-Module-Name) (!) Cant be installed due to a problem in children *(!)CPANPLUS-Dist-Gentoo: |-*(!)CPANPLUS: |_|-*(!)Archive::Extract: |_|__|-*(!)File::Path: |_|__|___|-!PathTools |_|__| |_|__|-!PathTools |_|__|-*IPC::Cmd |_|__|___|-+Locale::Maketext::Simple |_|__|___|-*Module::Load::Conditional |_|__|___|____|-+Locale::Maketext::Simple |_|__|___|____|-*Module::Load |_|__|___|____|_____|-+Test::Simple |_|__|___|____| |_|__|___|____|-*Params::Check |_|__|___|____|_____|-+Locale::Maketext::Simple |_|__|___|____|_____|-+Test::Simple |_|__|___|____| |_|__|___|____|-+Test::Simple |_|__|___|____|-+version |_|__|___| |_|__|___|-**Params::Check |_|__|___|-+Test::Simple |_|__| |_|__|-+Locale::Maketext::Simple |_|__|-**Module::Load::Conditional |_|__|-**Params::Check |_|__|-+Test::Simple |_| |_|-+Archive::Tar |_|-+Digest::MD5 |_|-*(!)File::Fetch |_|__|-**(!)File::Path |_|__|-!PathTools |_|__|-**IPC::Cmd |_|__|-+Locale::Maketext::Simple |_|__|-**Module::Load::Conditional |_|__|-**Params::Check |_|__|-+Test::Simple |_| |_|-+IO::Zlib |_|-**IPC::Cmd |_|-+Locale::Maketext::Simple |_|-*(!)Log::Message |_|__|-!PathTools |_|__|-+Locale::Maketext::Simple |_|__|-**Module::Load |_|__|-**Params::Check |_|__|-+Test::Simple |_| |_|-@(+)Module::CoreList |_|-**Module::Load |_|-**Module::Load::Conditional |_|-*Module::Loaded |_|__|-+Test::Simple |_| |_|_+Module::Signature |_|-*Object::Accessor |_|__|-**Params::Check |_|__|-+Test::Simple |_| |_|-+Package-Constants |_|-**Params::Check |_|-+Storable |_|-*(!)Term::UI |_|__|-+Locale::Maketext::Simple |_|__|-*(!)Log::Message::Simple |_|__|___|-**(!)Log::Message |_|__| |_|__|-**Params::Check |_|__|-+Test::Simple |_| |_|-+Test::Harness |_|-+Test::Simple |_|-+version | |-**(!)File::Path |-!PathTools |-**IPC::Cmd The problem here is mostly PathTools is not a module name, http://search.cpan.org/~smueller/PathTools-3.29/ And that cpan2dist refuses to fetch PathTools as-is [MSG] Checking if source files are up to date [MSG] Retrieving /root/.cpanplus/sourcefiles.2.18.stored [MSG] No '/root/.cpanplus/custom-sources' dir, skipping custom sources [ERROR] 'PathTools' does not contain an author part [ERROR] Cannot find 'PathTools' in the module tree And, that when given a link to the actual file: ie, cpan2dist $params http://search.cpan.org/CPAN/authors/id/S/SM/SMUELLER/PathTools-3.29.tar.gz It behaves as it should, downloads the file, and makes an ebuild. However, its the wrong ebuild. It for some reason creates perl-gcpan/File-Spec-3.29.ebuild, which makes reasonable sense, and is already in portage, and I'm guessing this is not the only package that behaves this way. SUMMARY OF MY ERATIC RANTINGS: 1) When forcefully generating PathTools ( somehow ), it should have some way of emitting a properly named ebuild. 2) Alternatively, there should be some way to create correct DEPENDS strings that depend on the right modules. Granted this is looking to be like a dark art because there's a great degree of inconsistency at present how gentoo deals with bundle/distribution/modules. ( Its getting better, but not perfect ) Other Things that cropped up in diagnosis of this problem: 1) There should be a way to depend on virtuals, if present, here's the present list in the main line: virtual/perl-Archive-Tar virtual/perl-CGI virtual/perl-Class-ISA virtual/perl-Compress-Raw-Zlib virtual/perl-Compress-Zlib virtual/perl-DB_File virtual/perl-Digest-MD5 virtual/perl-Digest-SHA virtual/perl-ExtUtils-CBuilder virtual/perl-ExtUtils-ParseXS virtual/perl-File-Spec virtual/perl-File-Temp virtual/perl-Getopt-Long virtual/perl-IO virtual/perl-IO-Compress-Base virtual/perl-IO-Compress-Zlib virtual/perl-IO-Zlib virtual/perl-Locale-Maketext-Simple virtual/perl-MIME-Base64 virtual/perl-Math-BigInt virtual/perl-Math-BigInt-FastCalc virtual/perl-Memoize virtual/perl-Module-Build virtual/perl-Module-Pluggable virtual/perl-Pod-Escapes virtual/perl-Pod-Simple virtual/perl-PodParser virtual/perl-Safe virtual/perl-Scalar-List-Utils virtual/perl-Storable virtual/perl-Sys-Syslog virtual/perl-Term-ANSIColor virtual/perl-Test virtual/perl-Test-Harness virtual/perl-Test-Simple virtual/perl-Text-Balanced virtual/perl-Time-HiRes virtual/perl-Time-Local virtual/perl-Time-Piece virtual/perl-digest-base virtual/perl-libnet virtual/perl-locale-maketext virtual/perl-net-ping virtual/perl-version These are file-less meta-packages, which are generally used to handle the "did this module suddenly move to core" scenarios. 2) There appears to be a bit of dependency leak, stuff directly depending on stuff that it doesn't need to depend on directly because its children do that for it. I can't tell if this is for certain however, its likely to be upstreams fault. SOLUTIONS? The most simple way to solve most of this problem, IMO, would be a mapping file of some sort, that is consulted as an override. A Config structure like this that could be loaded from a file and eval'd should likely cover most uses. my $config = { PathTools => [ # [ 0.0, 3.20, '>=perl-core/File-Spec-%v' ], # [ 3.20, 99.99, '>=dev-lang/perl-5.10' ] ], 'Module::CoreList' => [ # [ 0.0, 99.99, 'virtual/perl-Module-CoreList' ], ], 'Foo::Bar' => "perl-gcpanp/pants" };

Fri Dec 12 09:06:25 2008 vpit [...] cpan.org - Correspondence added

Hi. First, I'm truly impressed by the length of this report. Kudos! Show quoted text

> The problem here is mostly PathTools is not a module name, > http://search.cpan.org/~smueller/PathTools-3.29/

Well, actually the problem is that in portage the relevant package is named File-Spec, when it should really be PathTools. It makes more sense to name the ebuilds from the distribution than from the module, since a dist may bundle several modules (and in our case PathTools contains Cwd too), but since it's its name, so be it. That's why there was from the beginning a list of "gentooisms" in the code that map the Perl distribution names to their portage counterpart (when they differ). But I didn't use this list at the proper place, and it had no impact on the generated ebuilds - hence the bug. This should be fixed in git (see http://git.profvince.com/?p=perl/modules/CPANPLUS-Dist-Gentoo.git). Ideally, this list should be amendable by the end-user through some configuration file. This should answer the two first issues of your summary. Show quoted text

> 1) There should be a way to depend on virtuals, if present, here's the > present list in the main line: > > [...] > > These are file-less meta-packages, which are generally used to handle > the "did this module suddenly move to core" scenarios.

I think the current solution I use should cover those cases, as it lists all the possible categories in which the package could be located (perl-core, dev-perl, perl-gcpan, perl-gcpanp) - whether the relevant atoms really exist or not - and let emerge DTRT when its time comes. It's a little crude, but it saves me from trying to search into the portage tree for the real current name, which as you say could break ebuilds when packages move from one category from another. I agree that could be saved for packages that have a virtual, but it would still be needed for those which haven't. Show quoted text

> 2) There appears to be a bit of dependency leak, stuff directly > depending on stuff that it doesn't need to depend on directly because > its children do that for it. I can't tell if this is for certain > however, its likely to be upstreams fault.

If dist A depends on B v1, and C depends on A and on B v2, we need to explictely state the B dependency in both A and C. That's why every dependency advertised by the dist will result in a dependency in the ebuilds, and only those. If you have examples where perl and portage deps differ, I'd be happy to investigate a fix. Show quoted text

> > SOLUTIONS? > > The most simple way to solve most of this problem, IMO, would be a > mapping file of some sort, that is consulted as an override. > > A Config structure like this that could be loaded from a file and eval'd > should likely cover most uses. > > my $config = { > PathTools => [ > > # > [ 0.0, 3.20, '>=perl-core/File-Spec-%v' ], > > # > [ 3.20, 99.99, '>=dev-lang/perl-5.10' ]

This ain't right, because PathTools modules (File::Spec and Cwd) are dual-lived, which means that although they are bundled with perl, updates may be released through CPAN. And other modules may righteously depend on versions greater than the one installed with perl, so we should always explicitely depend on File-Spec. I know I often employ brute-force strategies, but I'd like to first have something that works before trying to be smart. I think g-cpan is sort of borked because it tried too hard at this. I hope this doesn't disappoint you. :) Many thanks again, Vincent.

Fri Dec 12 09:06:26 2008 The RT System itself - Status changed from 'new' to 'open'

Sat Dec 13 00:45:45 2008 kentfredric [...] gmail.com - Correspondence added

From:

kentfredric [...] gmail.com

On Fri Dec 12 09:06:25 2008, VPIT wrote: Show quoted text

> Well, actually the problem is that in portage the relevant package is > named File-Spec, when it should really be PathTools. It makes more

sense to name the ebuilds from the distribution than from the module, since a dist may bundle several modules (and in our case PathTools contains Cwd too), but since it's its name, so be it. Sure, but the problem here is that, even tho gentoo already has File-Spec, the cpan2dist + your extension combination tells me it does not know what I am talking about when I ask it to create "PathTools". The only way I could trick it into understanding was giving it the absolute URI of the right Tar.Gz file, which it then downloaded, unpacked, and then decided to ignore me and create File-Spec instead. So the problem is that the tool itself creates dependancies pointing to PathTools, but it itself generates the PathTools dep wrongly. Show quoted text

> I think the current solution I use should cover those cases, as it lists > all the possible categories in which the package could be located > (perl-core, dev-perl, perl-gcpan, perl-gcpanp) - whether the relevant > atoms really exist or not - and let emerge DTRT when its time comes. > It's a little crude, but it saves me from trying to search into the > portage tree for the real current name, which as you say could break > ebuilds when packages move from one category from another. I agree that > could be saved for packages that have a virtual, but it would still be > needed for those which haven't.

There are extra fun things here when packages get moved into the primary perl ebuild. For instance, for perls < 5.8, depending on the Module::Build was fine, but when perl 5.10 started hit the tree, the perl ebuild now contained Module::Build in such a configuration that Module::Build was no longer installable. I some cases, this is a combination of 2 packages sporting the same file in the same location, in conjunction with the COLLISION_PROTECT mechanism. Likewise, After manually hacking all the ebuilds depends above to DTRT, when I finally got to installing the CPANPLUS package i had generated, it bombed on me, simply for the fact it attempts to install scripts in /usr/bin which are already provided by the perl-5.10 ebuild. Back to the Module::Build problem, an easy way to solve this problem is the creation of virtual/perl-Module-Build and migrating old packages to this new virtual instead of the new, in essence, depending on functionality, not specific files. When 5.10 finally hits gentoo I would imagine either of these 2 structures occuring. 1. This requires changing every package that ever used module::build. package-> || ( ----> virtual/perl-Module-Build ---------------> perl-core/Module-Build ----> >=perl-5.10 ) or 2, simply stating that the virtualised functionality known as Module-Build can be provided by 1 of 2 sources, which only needs one file change. virtual/perl-Module-Build ||( >=perl-5.10 perl-core/Module-Build ) Obviously, this problem spurns from the integration of modules into the perl core package, but with no system metadata explaining which modules are provided by the core ebuild and which ones are accessories. Show quoted text

> > 2) There appears to be a bit of dependency leak, stuff directly > > depending on stuff that it doesn't need to depend on directly because > > its children do that for it. I can't tell if this is for certain > > however, its likely to be upstreams fault.

> > If dist A depends on B v1, and C depends on A and on B v2, we need to > explictely state the B dependency in both A and C. That's why every > dependency advertised by the dist will result in a dependency in the > ebuilds, and only those. If you have examples where perl and portage > deps differ, I'd be happy to investigate a fix.

You don't need to propagate dependencies recursively, this done at runtime by portage. Sure, If A *directly* uses B v1 and C directly uses B v2 and C depends A, then and only then do you need to state this. C \--B1 \--A ___\--B2 However, this is a concept of direct dependencies, any given ebuild only needs to specify the explicit set of ebuilds it directly uses, and rely on its own dependencies to likewise keep track of themself. But Noted, this doesn't appear to be actually a problem, I looked through the source of many items and they do appear to be actually directly using the different dependencies as shown in the above graph, Its just a bit weird for me as this model doesn't appear "normal" in some other situations. Show quoted text

> > > > SOLUTIONS? > > > > The most simple way to solve most of this problem, IMO, would be a > > mapping file of some sort, that is consulted as an override. > > > > A Config structure like this that could be loaded from a file and eval'd > > should likely cover most uses. > > > > my $config = { > > PathTools => [ > > > > # > > [ 0.0, 3.20, '>=perl-core/File-Spec-%v' ], > > > > # > > [ 3.20, 99.99, '>=dev-lang/perl-5.10' ]

> > This ain't right, because PathTools modules (File::Spec and Cwd) are > dual-lived, which means that although they are bundled with perl, > updates may be released through CPAN. And other modules may righteously > depend on versions greater than the one installed with perl, so we > should always explicitely depend on File-Spec.

Yeah, this was not necessarily an actual valid version map, I just made something Up on the fly for the point of an example. But being able to map modules directly to saying "perl provides this" is somewhat necessary under gentoo, due to the aforementioned collision safety mechanism. Its fine to have a dual-lifer with non-colliding files, but when you have colliding files, it doesn't like it because it loses the 'ebuild has known files' association that guarantees a sane system. ( /me remembers a case where a mysql build failed and tried to replace /usr/bin/test with its test-suite, really nasty ) Show quoted text

> I know I often employ brute-force strategies, but I'd like to first have > something that works before trying to be smart. I think g-cpan is sort > of borked because it tried too hard at this. I hope this doesn't > disappoint you. :)

g-cpan was good for some things, just sometimes it guessed wrong and assumed stuff didn't exist when it did, and made gross assumptions about where things were and how your system was configured ( very non-paludis friendly ). It worked ok with being given Distro' names, which cpan2dist's implementation just goes "eh what? PathTools? there is no associated author with that! die!" Configuration may be harder for new users, but id rather tell it exactly what to do, and take a while to do it, and have it work, then give it a general idea, have it not work, and being without a sufficient bludgeoning tool to force it to. Show quoted text

> Many thanks again, > > Vincent.

Thanks for the ever attentive response :) Kent.

Sun Dec 14 11:13:06 2008 vpit [...] cpan.org - Correspondence added

Show quoted text

> Sure, but the problem here is that, even tho gentoo already has > File-Spec, the cpan2dist + your extension combination tells me it does > not know what I am talking about when I ask it to create "PathTools". > > The only way I could trick it into understanding was giving it the > absolute URI of the right Tar.Gz file, which it then downloaded, > unpacked, and then decided to ignore me and create File-Spec instead.

That's because distributions aren't indexed on CPAN, but modules are. Any CPAN author can upload any distribution that contains any module, but the modules are only indexed if the author is recognized as authoritative. If you want to install by distribution name, you must provide its fully qualified name, which includes the author and the version (e.g. SMUELLER/PathTools-3.29.tar.gz). Show quoted text

> So the problem is that the tool itself creates dependancies pointing to > PathTools, but it itself generates the PathTools dep wrongly.

Creating ebuild dependencies to "PathTools" instead of "File-Spec" was indeed a bug, which I fixed. I don't see how that's related with the way CPAN handles distributions and modules. Show quoted text

> There are extra fun things here when packages get moved into the primary > perl ebuild. For instance, for perls < 5.8, depending on the > Module::Build was fine, but when perl 5.10 started hit the tree, the > perl ebuild now contained Module::Build in such a configuration that > Module::Build was no longer installable. > > I some cases, this is a combination of 2 packages sporting the same file > in the same location, in conjunction with the COLLISION_PROTECT

mechanism. Show quoted text

> > Likewise, After manually hacking all the ebuilds depends above to DTRT, > when I finally got to installing the CPANPLUS package i had generated, > it bombed on me, simply for the fact it attempts to install scripts in > /usr/bin which are already provided by the perl-5.10 ebuild.

Right, this can happen. But CPANPLUS (and hence /usr/bin/cpanp) is meant to be able to be updated from CPAN. The main perl ebuild shouldn't hold any authority on it. So what should be the preferred way to handle this? In the current state, it's possible to use the footer dist-option in those cases to specialize the install target (or whatever other trick). I'm not sure if that could reliably be automated. Show quoted text

> Back to the Module::Build problem, an easy way to solve this problem is > the creation of virtual/perl-Module-Build and migrating old packages to > this new virtual instead of the new, in essence, depending on > functionality, not specific files. When 5.10 finally hits gentoo I would > imagine either of these 2 structures occuring. > > 1. This requires changing every package that ever used module::build. > > package-> || ( > ----> virtual/perl-Module-Build > ---------------> perl-core/Module-Build > ----> >=perl-5.10 > ) > > or 2, simply stating that the virtualised functionality known as > Module-Build can be provided by 1 of 2 sources, which only needs one > file change. > > virtual/perl-Module-Build ||( >=perl-5.10 perl-core/Module-Build ) > > Obviously, this problem spurns from the integration of modules into the > perl core package, but with no system metadata explaining which modules > are provided by the core ebuild and which ones are accessories.

Isn't that exactly the role of the virtual to handle the "is perl >= 5.10" discussion? Would just depending on a virtual in this case (instead of on a normal dep) be enough to solve this at my level? Show quoted text

> You don't need to propagate dependencies recursively, this done at > runtime by portage. > > Sure, If A *directly* uses B v1 and C directly uses B v2 and C depends > A, then and only then do you need to state this. > > C > \--B1 > \--A > ___\--B2 > > However, this is a concept of direct dependencies, any given ebuild only > needs to specify the explicit set of ebuilds it directly uses, and rely > on its own dependencies to likewise keep track of themself. > > But Noted, this doesn't appear to be actually a problem, I looked > through the source of many items and they do appear to be actually > directly using the different dependencies as shown in the above graph, > Its just a bit weird for me as this model doesn't appear "normal" in > some other situations.

The generated ebuilds should exactly state the direct dependencies listed by the module author. I can't do much besides this. I won't look up in the ebuild dep tree to remove apparently redundant dependencies. One little change and all the ebuilds would have to be rewritten. Show quoted text

> g-cpan was good for some things, just sometimes it guessed wrong and > assumed stuff didn't exist when it did, and made gross assumptions about > where things were and how your system was configured ( very non-paludis > friendly ). It worked ok with being given Distro' names, which > cpan2dist's implementation just goes "eh what? PathTools? there is no > associated author with that! die!"

And that's the sane thing to do. It's the way the cpan and cpanp command-line tools handle it. The magic g-cpan uses to go around this is deemed to break in many cases.

Sun Dec 14 13:26:42 2008 kentfredric [...] gmail.com - Correspondence added

From:

kentfredric [...] gmail.com

On Sun Dec 14 11:13:06 2008, VPIT wrote: Show quoted text

> That's because distributions aren't indexed on CPAN, but modules are. > Any CPAN author can upload any distribution that contains any module, > but the modules are only indexed if the author is recognized as > authoritative. If you want to install by distribution name, you must > provide its fully qualified name, which includes the author and the > version (e.g. SMUELLER/PathTools-3.29.tar.gz).

Ah. I figured there was an easy way to somehow resolve whatever the "latest" realse of a given distribution was resolved as. Show quoted text

> Creating ebuild dependencies to "PathTools" instead of "File-Spec" was > indeed a bug, which I fixed. I don't see how that's related with the way > CPAN handles distributions and modules.

Cool. Not really related I guess then :). Show quoted text

> Right, this can happen. But CPANPLUS (and hence /usr/bin/cpanp) is meant > to be able to be updated from CPAN. The main perl ebuild shouldn't hold > any authority on it. > > So what should be the preferred way to handle this? In the current > state, it's possible to use the footer dist-option in those cases to > specialize the install target (or whatever other trick). I'm not sure if > that could reliably be automated.

The annoying thing is primarily how collision protect works. Its rather naive and doesn't actually test package ownership of the files at install time. All it does is check the filesystem before the final copy phase for files that might be replaced and then dies if those files exist and are not owned by the previous version of the same package (in the same slot at that), in essence: @collisions = (); for my $file ( @files_to_install ){ next if( ! -f $file ); next if( grep { $_ == $file }, @previous_versions_files_same_slot ); push @collsions , $file; } die sprintf( "cant merge, collisions: %s\n", join(",\n", @collisions )) if @collisions; Emerge generally spends a lot of time here reverse looking up which package is recorded as creating that file( if any ) to help the user diagnose the problem ( its very resource intensive, which is why its not used at runtime as the main rule ). For this reason, if any given module happened to be installed manually by a user(outside of portage), upon using an ebuild to merge that same module collision protect would generally kick in and tell the user there was a bunch of files that already existed and ask them to solve the problem. ( Its generally accepted 2 ebuilds in portage installing the exact same file is an error/bug , and if its not resolvable, they mark blockers on the packages to stop it trying back at the dependacy resolution phase. ) Its generally gentoo being cautious and assuming the average install application cant be relied upon to provide a complete ( and safe ) deinstallation phase later, which leaves cruft and security risks lying around, which is the whole reason I'm more or less using ebuilds instead of just directly installing into the filesystem with CPAN, I like the atomicity of it all. What I've been doing for things at present that are problematic, or provided by something else already in-system, is using the --ignore / --ignorelist feature to progressively weed out problem dependacies, but I don't feel justified using that as the solution everywhere, it just feels dirty making gross assumptions as to what is and what isn't available. Granted its conceptually impossible at present to just make this up at present automatically without epic develop overhead. Show quoted text

> Isn't that exactly the role of the virtual to handle the "is perl >= > 5.10" discussion? > > Would just depending on a virtual in this case (instead of on a normal > dep) be enough to solve this at my level? >

You could just add a virtual depend on every module line, but that would be behaviourally limited, as it assumes things about the ability for virtuals to solve the problem. Having seen the already exhaustive list of search places, it can only go on so far before it becomes a problem ( im really hoping its stopped growing if you did add virtuals, but can't be certain. ), it might solve the problem in some cases, but in other cases, there are situations where virtuals are needed but nobodys' created them yet. To me, it would be more futuresafe to have a "Do Instead" file of sorts, which can be used to add custom rules based on known patterns, sort of like the gentoosims hash, just with enough flexibility to add more atom parts, or multiple atom parts, and let the person using the script decide which dependency trick works the best, and possibly provide a sample substitution file with a list of "common problems" in it. Also, The ordering of the rules however is somewhat important. For instance, || ( perl-core/Module-Build virtual/perl-Module-Build Show quoted text

>=dev-lang/perl-5.10 )

Is bad, ( I can't explain why right now :( , its experiential, it doesn't like it , you end up trying to pull Module-Build and having it die on depend collision , It might be repository priority oriented, but I haven't worked out the reason yet ) || ( virtual/perl-Module-Build perl-core/Module-Build ) Is however much better, and a simple virtual/perl-Module-Build is better again, so if/when deciding how to implement a substition system, making it flexible enough for the writers of substitutive rules to create them in safe ways. This solution saves you from having to fix the real problem, but makes solving the problem on a case-by-case basis easy for users. Hope this is of use, --Kent.

Sun Jan 25 19:33:30 2009 vpit [...] cpan.org - Correspondence added

As I said on IRC, portage is no longer happy with DEPENDs that look like "|| ( cat1/foo ... cat$n/foo )" with any of the cat$x/foo not actually existing in the portage tree. This forced me to change the dependency logic to this : when generating DEPEND for a dist, all the portage trees are scanned (this means PORTDIR, PORTDIR_OVERLAY, and the overlay passed to cpan2dist - in this order) for a corresponding package whose name may have been relinked through the gentooisms (and with a sufficient version if needed, otherwise it searches further) in the categories 'virtual', 'perl-core', 'dev-perl', 'perl-gcpan' and 'perl-gcpanp' - in this order. I preferred the old dynamic solution of letting portage sort out which package to pull (asserting that the perl-gcpanp was always present), but there was no other solution. As a result of this, the deps are now much cleaner, but also much more sensible to category changes. An idea to overcome this would be to, when an ebuild is regenerated and that the version didn't change, to parse the old ebuild's deps and to compare them with the new ones - if they're different, the new ebuild would be generated with a -r($n+1) suffix. About virtuals not doing what they are expected to do, I don't think it's my job to do something about it. It's their role to assert that a given dist is installed ; and if they fail at doing this, then the problem should be addressed at their level. Adding up piles of workarounds is always deemed to collapse. Same goes for dual-lifed modules : the main perl ebuild has no reason to keep ownership on them, and this should be fixed there. Module::Build may indeed need some special handling, as CPANPLUS doesn't add it to the dependency list. Problems may arise on fresh gentoo systems where it's not installed yet. There are a few other fixes beyond 0.05 that are ready into git. If you have some spare time to test, I'd be very happy to hear some feedback from you or any other gentoo people. Vincent.

Sat Feb 14 06:53:59 2009 vpit [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Feb 14 06:54:05 2009 vpit [...] cpan.org - Fixed in 0.05 added