Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: Alexis Ballier <aballier@g.o>, Zac Medico <zmedico@g.o>
Cc: gentoo-dev@l.g.o, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Date: Tue, 20 Jan 2015 17:28:45
Message-Id: 54BE9035.1080009@gentoo.org
In Reply to: Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= ) by Alexis Ballier
1 On 01/20/2015 01:11 AM, Alexis Ballier wrote:
2 > On Tue, 20 Jan 2015 01:01:41 -0800
3 > Zac Medico <zmedico@g.o> wrote:
4 >
5 >> On 01/20/2015 12:13 AM, Alexis Ballier wrote:
6 >>> On Mon, 19 Jan 2015 20:31:45 +0100
7 >>> Michał Górny <mgorny@g.o> wrote:
8 >>>> 2. Subslots work correctly. Rebuilds are forced when the chosen
9 >>>> library is upgraded. Moreover, USE flag change causes a rebuild
10 >>>> when user decides to change the ffmpeg provider.
11 >>>
12 >>>
13 >>> No offense, but this argument is complete crap. You should rather
14 >>> fix portage bugs than propose to introduce tree-wide changes to
15 >>> hide them... More precisely: || ( a:= b c:= d ) is perfectly
16 >>> defined (in the "what it means" sense, not in PMS sense). When the
17 >>> package is built, if 'a' is satisfied then a (and its subslot) is
18 >>> added to the subslot list of the package; ditto for c. You end up
19 >>> with a list of subslot deps, that you can store in vdb or whatever,
20 >>> and use that to decide when to rebuild the package.
21 >>
22 >> That's an interesting proposal, but I immediately find myself
23 >> questioning how closely it models reality. For example, maybe the
24 >> package links to both the a:= package and c:= package, or maybe just
25 >> to one of them. Shouldn't our model match reality as closely as
26 >> possible, as long as it's practical?
27 >
28 > Do you have any such example ?
29
30 Well, I think this demonstrates the sorts of ambiguities that may arise
31 when using || deps to model reality. We may find that replacing || deps
32 with USE conditionals and REQUIRED_USE constraints gives us a more
33 accurate and practical model for some kinds of dependencies.
34
35 > I think we can only make the safest assumption. Even without subslot,
36 > if you consider this: || ( a b c d ), with a and c installed but
37 > package automagically deciding to use only a, how can a PM decide
38 > whether it is safe to remove a or not after the package has been
39 > merged ?
40
41 Right, this demonstrates that || deps are ambiguous. So, maybe we should
42 look at alternatives that are not so ambiguous, such as USE conditionals
43 and REQUIRED_USE constraints.
44 --
45 Thanks,
46 Zac

Replies