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