Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Alexis Ballier <aballier@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Date: Wed, 21 Jan 2015 18:21:47
Message-Id: 20150121192128.3b3aab4b@pomiot.lan
In Reply to: Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= ) by Alexis Ballier
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

Replies