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