On 4 July 2012 02:16, Michał Górny <email@example.com> 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
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
a) sometimes install code from CPAN
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 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
*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
> Best regards,
> Michał Górny
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"