1 |
Am Freitag 27 April 2012, 13:35:21 schrieb Chí-Thanh Christopher Nguyễn: |
2 |
> Ciaran McCreesh schrieb: |
3 |
> >> * two new files in profile directories supported, |
4 |
> >> package.use.stable.mask and package.use.stable.force |
5 |
> >> * syntax is identical to package.use.mask and package.use.force |
6 |
> >> * meaning is identical to package.use.mask and package.use.force, |
7 |
> >> except that the resulting rules are ONLY applied iff a stable keyword |
8 |
> >> is in use |
9 |
> > |
10 |
> > This means that an ebuild will effectively change when moved from ~arch |
11 |
> > to arch. The point of ~arch is to test ebuilds before they're moved to |
12 |
> > arch. |
13 |
> |
14 |
> I agree that the ~arch ebuilds should be tested in the same |
15 |
> configuration in which they will end up in arch. However in this case, |
16 |
> the possible configurations for arch are a subset of those in ~arch, so |
17 |
> the testing covers those too. |
18 |
|
19 |
Right now, it's more likely that just before filing the stablerequest an |
20 |
ebuild is modified such that the useflag disappears and all the conditional |
21 |
codeblocks are set to a fixed value. (Compare cups-1.5.2-r3 and -r4) That |
22 |
includes a much larger danger of mistakes creeping in. |
23 |
|
24 |
Just forcing an useflag on or off poses a fairly minimal intrusion. |
25 |
|
26 |
> I see a problem where a significant proportion of ~arch users will have |
27 |
> this flag enabled (which is obviously the point of |
28 |
> package.use.stable.mask) so the arch configurations will see fewer |
29 |
> testers. This issue may need to be addressed, e.g. by extending |
30 |
> stabilization period or disallowing package.use.stable.mask in default |
31 |
> or desktop profile. |
32 |
|
33 |
Well, at least in some use cases the useflag will have an obvious disadvantage |
34 |
(remember the many libusb-backend bugs in cups-1.4). Then the consensus would |
35 |
have been "you can use this but it's not as bug-free", there may have been |
36 |
even an ewarn about it, ... |
37 |
|
38 |
Cheers, |
39 |
Andreas |
40 |
|
41 |
-- |
42 |
|
43 |
Andreas K. Huettel |
44 |
Gentoo Linux developer |
45 |
dilfridge@g.o |
46 |
http://www.akhuettel.de/ |