Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Cc: Sergey Popov <pinkbyte@g.o>
Subject: Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
Date: Mon, 09 Dec 2013 16:06:19
In Reply to: Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead? by Tom Wijsman
1 On Mon, Dec 9, 2013 at 5:55 AM, Tom Wijsman <TomWij@g.o> wrote:
2 > For the dependency syntax, having :* as a default breaks things or
3 > causes a lot of work. If explicit slots (or :0) were the default, it
4 > works and you spare out dealing with lots of reverse dependencies when
5 > you introduce a new slot.
7 I was giving this some more thought and here is another way of looking at this.
9 Let A be the set of all situations where it makes sense to create a
10 new slot for a package that has reverse dependencies.
12 Let B be the subset of A where it makes sense for those reverse
13 dependencies to automatically use the new slot without any
14 intervention by the reverse dep maintainers.
16 If |B| >> |A \ B| then the current default makes sense. (That is, if
17 the number of elements in B is much larger than the number of elements
18 in A that aren't in B.)
20 If |B| << |A \ B| then it would make sense to require all slot
21 dependencies to be explicit, and the ":*" dependency to be frowned
22 upon in general.
24 I think that the above just makes sense if you think about it, so I'll
25 use that as my initial premise for what follows. By all means
26 challenge this.
28 So, what I'm going to do now is speculate that B = ∅ (that is B is the
29 empty set). Therefore, it makes sense to get rid of the current
30 default and require all slot deps to be explicit.
32 If you think that B isn't the empty set, it is trivial for you to
33 demonstrate that this is the case. Simply give me a single example of
34 a situation where:
35 1. It makes sense for a dep to use a new slot.
36 2. It makes sense for all of its reverse deps to automatically use
37 the new slot without any further intervention by the individual
38 reverse dep maintainers.
40 I can't think of any, and I'm all ears if somebody else can. It seems
41 to me that our current default optimizes for a situation that is
42 dubious from a QA standpoint. Its main virtue is that you don't have
43 to go look up what the current slot is for slot-less packages, but
44 honestly if you just stuck a :0 on every line of your ebuild chances
45 are it would work on the first install and at least the behavior would
46 be consistent for anybody else who uses it.
48 Rich