1 |
On Tue, 3 Jul 2012 21:05:46 +1200 |
2 |
Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
|
4 |
> On 3 July 2012 20:24, Michał Górny <mgorny@g.o> wrote: |
5 |
> > |
6 |
> > --depclean? |
7 |
> |
8 |
> eix Module-Metadata |
9 |
> [I] perl-core/Module-Metadata |
10 |
> Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9 <--- |
11 |
> not unmasked by --autounmask |
12 |
> Installed versions: 1.0.6(15:59:00 06/26/12) |
13 |
> Homepage: http://search.cpan.org/dist/Module-Metadata/ |
14 |
> Description: Gather package and POD information from perl |
15 |
> module files |
16 |
> |
17 |
> [I] virtual/perl-Module-Metadata |
18 |
> Available versions: ~1.0.3 ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1 |
19 |
> <----- Unmasked by --autounmask |
20 |
> Installed versions: 1.0.9-r1(09:37:51 07/02/12) |
21 |
> Description: Virtual for Module-Metadata |
22 |
> |
23 |
> perl-Module-Metadata-1.0.9.ebuild |
24 |
> |
25 |
> RDEPEND="|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )" |
26 |
> |
27 |
> It appears yes, --depclean *will* reap perl-core/* in this scenario ( |
28 |
> portage 2.2.0_alpha114 ) |
29 |
> |
30 |
> Just I don't tend to use --depclean an awful lot. Usually, I don't |
31 |
> expect to have to use --depclean to avoid a somewhat "broken" system. |
32 |
|
33 |
Yes. Which simply means that something is broken with dependencies. |
34 |
And by that I mean that either: |
35 |
|
36 |
a) || ( a b ) should be || ( b a ), to actually state what perl does, |
37 |
b) perl should be modified to work like our deps specify. |
38 |
|
39 |
> > Doesn't perl-cleaner handle perl upgrades for this? And the tested |
40 |
> > ABI_SLOTs should help with that too. |
41 |
> |
42 |
> ABI_SLOT may be able to help, but the problem is that installing |
43 |
> perl-core/foo-1.0 on perl-5.10 which ships foo-2.0 , is 100% fine. |
44 |
> |
45 |
> It will just shadow the 2.0 version with the 1.0 version, and assume |
46 |
> "that is what you want", while the virtual is trying to convey "That |
47 |
> is not what we want". |
48 |
|
49 |
If user intentionally installs an older version, he should be aware |
50 |
that the result will be having the older version rather than the newer |
51 |
one. I think we shouldn't prevent that. |
52 |
|
53 |
> > This is a really fragile approach, and is mostly a workaround |
54 |
> > to the real issue. You want to say «I need *only* one of my |
55 |
> > dependencies satisfied» while you actually get «if I'm installed, |
56 |
> > then let every my dependency in those blocks actually block each |
57 |
> > other». |
58 |
> > |
59 |
> > That's just impossible to achieve. Think of ^^ ( foo bar ). When |
60 |
> > the package gets installed, foo is installed and bar is not. Then |
61 |
> > you want to emerge bar. What should happen? |
62 |
> > |
63 |
> > a) you want portage to refuse to do that. Why would it? AFAIU this |
64 |
> > would no longer be a problem actually. |
65 |
> |
66 |
> Given |
67 |
> |
68 |
> C = " ^^( a b )" and you had "A and C" in your world, and you wanted |
69 |
> to install B, portage would tell you that to do that, you would have |
70 |
> to remove either A or C. ( Yay, the communicative property of XOR :D |
71 |
> ) |
72 |
> |
73 |
> > b) you want portage to do that. But you just forced it unmerge it? |
74 |
> > It will install the previously made binary package and it's back... |
75 |
> |
76 |
> I can't parse this statement. Sorry :/ |
77 |
|
78 |
Nevermind it. It was an assumption that a & b could be fine together |
79 |
later on but I'm not sure if it was really on the topic. |
80 |
|
81 |
> > c) you want portage to unmerge foo because the dep will now be |
82 |
> > satisfied by bar. Wait... unmerge perl? |
83 |
> |
84 |
> No, perl would never be removed, not unless the ^^( ) was simply |
85 |
> |
86 |
> "^^( perl foo )" |
87 |
> |
88 |
> In practice, it would be "^^( =dev-lang/perl-5.16* =foo-5.0 )" which |
89 |
> would mean |
90 |
> |
91 |
> a) remove foo |
92 |
> b) downgrade/upgrade dev-lang/perl |
93 |
> |
94 |
> of course, I have noticed a fly in my ointment, in that this logic |
95 |
> would mean this blocker could be avoided by down/upgrading foo, which |
96 |
> is precisely what we want to avoid. So its back to the drawing board. |
97 |
|
98 |
I don't really think we allow blockers to enforce upgrades/downgrades. |
99 |
|
100 |
> I have thought of scrapping the virtuals entirely and handling it so |
101 |
> that things depend on perl-core/* instead, and perl-core can just |
102 |
> dynamically decide at install time whether or not it needs to no-op ( |
103 |
> and sometimes perl-core/* will need to hard depend on perl and just |
104 |
> install nothing ). |
105 |
> |
106 |
> This seems a simpler approach until you consider the problem of "How |
107 |
> do we determine dependencies for this ebuild". |
108 |
|
109 |
Do you actually need to do that? All those ebuilds will depend on perl |
110 |
with minimal version number necessary for the package to build. |
111 |
|
112 |
If perl is older, the package will be built normally. If perl is newer, |
113 |
the package will install a no-op. It's fine unless you consider |
114 |
downgrading perl. But thinking about it... any upgrade or downgrade of |
115 |
perl breaks all the modules anyway. |
116 |
|
117 |
About other package dependencies, they're probably fine in both cases. |
118 |
If a newer perl provides the particular module, all its dependencies |
119 |
have to be satisfied in perl anyway. So it will just pull more |
120 |
'virtuals'. |
121 |
|
122 |
-- |
123 |
Best regards, |
124 |
Michał Górny |