Gentoo Archives: gentoo-dev

From: heroxbd@g.o
To: gentoo-dev@l.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 03:19:23
Message-Id: 86ppp6u2xc.fsf@moguhome00.in.awa.tohoku.ac.jp
In Reply to: Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead? by Rich Freeman
1 [reordered to ease replying]
2
3 Rich Freeman <rich0@g.o> writes:
4 > Now, perhaps a more balanced approach might be to mask it and give 15
5 > days notice on -dev, and then it can be unmasked. Anybody who cares
6 > about the library can test the new version, and if necessary update
7 > their dependencies to use the previous slot only (and if 15 days isn't
8 > enough time they can just update the dep right away and then update it
9 > again after they get around to testing it). Those who don't want to
10 > have to deal with that can just define their slot dependencies
11 > explicitly so that this policy will never apply to them.
12
13 Good idea!
14
15 > The problem with this is that it puts the onus on the person who wants
16 > to make forward progress (adding support for a new library version).
17 > That means that they have incentive to either not bother with the new
18 > library version (causing Gentoo to stagnate), or use hacks like giving
19 > the library a new name (which we have examples in the tree of).
20
21 > In order for a QA policy to be effective it has to either be minimally
22 > intrusive, or make the cost of compliance lower than the cost of
23 > workarounds or benign neglect. People don't HAVE to maintain
24 > packages, after all...
25
26 I agree with that. We are all aware that every gcc slot bump costs so
27 much work (and frustration).
28
29 At the same time, it worth the hard work for a well-organized tree and
30 flexibility.
31
32 The only draw back is lack of man power to do it right like bug
33 493652. Yes, when a library introduces a new not fully compatible
34 version, it naturally implies a lots of work to do for downstream like
35 us. There is no escape: If we hack a versioned library name, it will
36 bite us in the future. The question becomes: Who should do this heavy
37 lifting?
38
39 This is a glitch in the amount of work needed when a single-slotted
40 library suddenly becomes slotted. IMHO, let's form a slotting group in
41 the reformed QA team who will donate manpower for such situation to aid
42 the library maintainer. Anyone who wants to make forward progress but
43 does not have enough time seeks help to the slotting group.
44
45 What do you say?
46
47 Benda