On Wed, 4 Jul 2012 05:49:08 +1200 Kent Fredric <kentfred...@gmail.com> wrote:
> 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. I was saying the other way -- always specify the complete deps. If you install it on older perl, it will work. If you install it on newer perl, it shouldn't involve installing anything which is not necessary (or already integrated into perl) anyway. > 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 > > > -- Best regards, Michał Górny
signature.asc
Description: PGP signature
