On 4 July 2012 02:16, Michał Górny <mgo...@gentoo.org> wrote: >> I have thought of scrapping the virtuals entirely and handling it so >> that things depend on perl-core/* instead, and perl-core can just >> dynamically decide at install time whether or not it needs to no-op ( >> and sometimes perl-core/* will need to hard depend on perl and just >> install nothing ). >> >> This seems a simpler approach until you consider the problem of "How >> do we determine dependencies for this ebuild". > > Do you actually need to do that? All those ebuilds will depend on perl > with minimal version number necessary for the package to build. > > If perl is older, the package will be built normally. If perl is newer, > the package will install a no-op. It's fine unless you consider > downgrading perl. But thinking about it... any upgrade or downgrade of > perl breaks all the modules anyway.
The problem occurs in a few edge cases, which, fortunately don't happen often. Usually its when packages appear as new additions to dev-lang/perl. ie: When AAAAAAA is added to perl, on perls older than 5.something have to install all of AAAAAA's deps . ( Which are ussually provided by perl anyway, so its not a problem ). But if *2* things are added between perl releases and one depends on the other, ie: AAA and BBB are added to perl 20, installing them on perl 15 will require you to install BBB before installing AAA. Granted I can't think of any modules that do exactly this off the top of my head, but its something to think about. ( Perhaps some things like CPANPLUS and other things that are miles ahead of the perl verision and have external deps ), but fair to say, I think a module that can a) sometimes install code from CPAN but b) has no DEPENDS on other perl modules ( because you want to have no depends if it is going to just no-op ) Is a recipe for disaster. And the more I think about doing it with USE_EXPAND/USE flags with 1-flag-perl-perl-version[1] the more It feels like it would be a bigger nightmare than what we're currently doing. What we're doing works atm, just it has the annoying quirks that come up from time to time, notably more around perl releases, and these quirks slowdown stabilizations. *1 : ( though they've tended away from changing versions of bundled libs with maintenance releases these days so its not so much a visible problem if we stick to the Majors, it can still happen that the version of a module can change between releases, and somebody could plausibly depend on the more recent of the 2 versions ) > If a newer perl provides the particular module, all its dependencies > have to be satisfied in perl anyway. So it will just pull more > 'virtuals'. > > -- > Best regards, > Michał Górny -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
