1 |
Dnia 2015-01-21, o godz. 12:12:21 |
2 |
Alexis Ballier <aballier@g.o> napisał(a): |
3 |
|
4 |
> On Wed, 21 Jan 2015 11:15:04 +0100 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> |
7 |
> > Dnia 2015-01-21, o godz. 11:05:01 |
8 |
> > Alexis Ballier <aballier@g.o> napisał(a): |
9 |
> > |
10 |
> > > > > > 2. Subslots work correctly. Rebuilds are forced when the |
11 |
> > > > > > chosen library is upgraded. Moreover, USE flag change causes |
12 |
> > > > > > a rebuild when user decides to change the ffmpeg provider. |
13 |
> > > > > |
14 |
> > > > > No offense, but this argument is complete crap. You should |
15 |
> > > > > rather fix portage bugs than propose to introduce tree-wide |
16 |
> > > > > changes to hide them... More precisely: || ( a:= b c:= d ) is |
17 |
> > > > > perfectly defined (in the "what it means" sense, not in PMS |
18 |
> > > > > sense). When the package is built, if 'a' is satisfied then a |
19 |
> > > > > (and its subslot) is added to the subslot list of the package; |
20 |
> > > > > ditto for c. You end up with a list of subslot deps, that you |
21 |
> > > > > can store in vdb or whatever, and use that to decide when to |
22 |
> > > > > rebuild the package. |
23 |
> > > > |
24 |
> > > > Following a specification is not a bug. I could argue here a lot |
25 |
> > > > but... just implement it. And return to us when you do. We had an |
26 |
> > > > item for this for EAPI 6, and it was removed because nobody |
27 |
> > > > volunteered to implement it. In fact, nobody even were able to |
28 |
> > > > fully specify what it should do... but if you want to discuss |
29 |
> > > > that, please start a new thread, possibly at the -pms list. |
30 |
> > > |
31 |
> > > Above is a simple algorithm that works in all cases. What you're |
32 |
> > > asking me to do is "go beg pms list to allow something they don't |
33 |
> > > want because the subslot/:= spec was poorly written and thought |
34 |
> > > of". I already gave you the solution, don't count on me for the |
35 |
> > > administrative work :=) (NB: everytime I tried to improve/fix |
36 |
> > > something in pms I failed miserably, so that I have no other choice |
37 |
> > > but giving up on this, check bgo) |
38 |
> > |
39 |
> > No, it works in the one case you thought of. Two quick issues: |
40 |
> |
41 |
> Ok, so first thing: You are the one writing about putting || in |
42 |
> "effective deps" (whatever that means), for me := deps that apply when |
43 |
> the package is installed is just a list created when the package is |
44 |
> built: no ||, no use conditional, and with subslots instantiated. |
45 |
|
46 |
I'm just describing the current Portage behavior. By 'effective deps' I |
47 |
mean 'what Portage puts in depgraph' when it sees || ( a:= b:= ). |
48 |
|
49 |
> |
50 |
> > 1. What does || ( a b:= c:= ) mean? i.e. only some having subslots. |
51 |
> |
52 |
> This makes sense only when in DEPEND+RDEPEND (because of the :=), so |
53 |
> apply this (mostly copy/paste) for all such deps: |
54 |
> for a in 'a' 'b' 'c': |
55 |
> When the package is built, if 'a' is satisfied and has a := |
56 |
> dep then 'a' and its subslot is added to := deps list for the |
57 |
> installed package |
58 |
> |
59 |
> As for the meaning, it uses all of a, b and c that are available at |
60 |
> buildtime and at least one of them must be present. |
61 |
> for 'b' and 'c', the := dep description/meaning from pms applies. |
62 |
> |
63 |
> > 2. What does || ( a:= b:= ) mean when a and b can be both installed? |
64 |
> |
65 |
> Ditto. |
66 |
|
67 |
A fair bit inconsistent but I guess it is the safe solution. Of course, |
68 |
it is ugly for making || () behave completely different from |
69 |
the original meaning when := is used inside. You add subslot, you get |
70 |
completely different behavior. You remove it, you get completely |
71 |
different behavior... |
72 |
|
73 |
> > Adding a very specific PMS rule for two packages doesn't sound like |
74 |
> > a very good idea to me. |
75 |
> |
76 |
> I agree but I don't think it is that specific. |
77 |
> |
78 |
> > > Moreover, when I bumped ffmpeg subslot, portage did rebuild all |
79 |
> > > those packages with || ( := := ) deps properly for me. So, you'll |
80 |
> > > have to be a bit more specific on what goes wrong than 'broken || |
81 |
> > > ( libav:= ffmpeg:= )'... |
82 |
> > |
83 |
> > I already told you that before. Try switching from ffmpeg to libav, |
84 |
> > and see what mess it causes. I'll summarize it for you: |
85 |
> > |
86 |
> > 1. if you have dynamic-deps enabled, portage will want to install both |
87 |
> > ffmpeg (because of :=) and libav (because of ||). The effective |
88 |
> > deps will look like: |
89 |
> > |
90 |
> > || ( ffmpeg:0/51= libav ) ffmpeg:0/51= |
91 |
> |
92 |
> with a separate := deps list, you have 'ffmpeg:0/51=' in the list; you |
93 |
> notice ffmpeg subslot has changed from '0/51' to '' (since it is not |
94 |
> installed anymore) so trigger the package for rebuild and use the || |
95 |
> ( ffmpeg:= libav:= ) dep (which I assume works fine since that's what |
96 |
> happens when you install the package). the bug here is that portage |
97 |
> uses a crafted (r)depend string for reinstall, instead of the ones |
98 |
> from the stock ebuild from either vdb or the portage tree. |
99 |
> |
100 |
> > 2. If you have dynamic-deps disabled, portage will happily switch impl |
101 |
> > without rebuilding revdeps (breakage). Afterwards, it will allow |
102 |
> > upgrading the other dep (libav) without rebuilds. The effective deps |
103 |
> > will look like: |
104 |
> > |
105 |
> > || ( ffmpeg:0/51= libav ) |
106 |
> |
107 |
> this is also solved by having a separate := dep list in vdb |
108 |
|
109 |
It is easy to write others how to do stuff without looking at the code, |
110 |
isn't it? |
111 |
|
112 |
-- |
113 |
Best regards, |
114 |
Michał Górny |