1 |
On Tue, 20 Jan 2015 09:28:21 -0800 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
|
4 |
> On 01/20/2015 01:11 AM, Alexis Ballier wrote: |
5 |
> > On Tue, 20 Jan 2015 01:01:41 -0800 |
6 |
> > Zac Medico <zmedico@g.o> wrote: |
7 |
> > |
8 |
> >> On 01/20/2015 12:13 AM, Alexis Ballier wrote: |
9 |
> >>> On Mon, 19 Jan 2015 20:31:45 +0100 |
10 |
> >>> Michał Górny <mgorny@g.o> wrote: |
11 |
> >>>> 2. Subslots work correctly. Rebuilds are forced when the chosen |
12 |
> >>>> library is upgraded. Moreover, USE flag change causes a rebuild |
13 |
> >>>> when user decides to change the ffmpeg provider. |
14 |
> >>> |
15 |
> >>> |
16 |
> >>> No offense, but this argument is complete crap. You should rather |
17 |
> >>> fix portage bugs than propose to introduce tree-wide changes to |
18 |
> >>> hide them... More precisely: || ( a:= b c:= d ) is perfectly |
19 |
> >>> defined (in the "what it means" sense, not in PMS sense). When the |
20 |
> >>> package is built, if 'a' is satisfied then a (and its subslot) is |
21 |
> >>> added to the subslot list of the package; ditto for c. You end up |
22 |
> >>> with a list of subslot deps, that you can store in vdb or |
23 |
> >>> whatever, and use that to decide when to rebuild the package. |
24 |
> >> |
25 |
> >> That's an interesting proposal, but I immediately find myself |
26 |
> >> questioning how closely it models reality. For example, maybe the |
27 |
> >> package links to both the a:= package and c:= package, or maybe |
28 |
> >> just to one of them. Shouldn't our model match reality as closely |
29 |
> >> as possible, as long as it's practical? |
30 |
> > |
31 |
> > Do you have any such example ? |
32 |
> |
33 |
> Well, I think this demonstrates the sorts of ambiguities that may |
34 |
> arise when using || deps to model reality. We may find that replacing |
35 |
> || deps with USE conditionals and REQUIRED_USE constraints gives us a |
36 |
> more accurate and practical model for some kinds of dependencies. |
37 |
|
38 |
for the above example, yes of course, but this is because it is |
39 |
another instance of automagic deps since you don't control to what the |
40 |
package links to. |
41 |
|
42 |
> > I think we can only make the safest assumption. Even without |
43 |
> > subslot, if you consider this: || ( a b c d ), with a and c |
44 |
> > installed but package automagically deciding to use only a, how can |
45 |
> > a PM decide whether it is safe to remove a or not after the package |
46 |
> > has been merged ? |
47 |
> |
48 |
> Right, this demonstrates that || deps are ambiguous. So, maybe we |
49 |
> should look at alternatives that are not so ambiguous, such as USE |
50 |
> conditionals and REQUIRED_USE constraints. |
51 |
|
52 |
if you assume there are no automagic deps, what is wrong and/or |
53 |
ambiguous with '|| ( a b c d ) means "any of them, and at least all |
54 |
that were available when the package was merged"' ? |
55 |
in the above example this avoids PM breaking people systems by removing |
56 |
'a' (e.g. if another packages pulls in 'd' that has a blocker against |
57 |
'a') and as a side effect makes := deps work... |
58 |
|
59 |
Alexis. |