1 |
On 12/18/2010 01:57 AM, Fabian Groffen wrote: |
2 |
> On 18-12-2010 02:45:06 +0100, Arfrever Frehtes Taifersar Arahesis wrote: |
3 |
>> |
4 |
>> Problem #1: USE flags cannot contain "." characters. |
5 |
>> |
6 |
>> The following solutions have been suggested: |
7 |
>> - Add support for "." characters in USE flags in EAPI="4". |
8 |
> |
9 |
> Like Donnie said, this feels like a purely cosmetic change. I think |
10 |
> that alone is not a good reason to do this. |
11 |
> |
12 |
>> Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable |
13 |
>> packages (usually until these packages are stabilized). |
14 |
>> |
15 |
>> Example of the problem: |
16 |
>> If "python_abis_2.7", "python_abis_3.1" and "python_abis_3.2" USE flags are masked using |
17 |
>> use.mask on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these |
18 |
>> architectures, then majority of reverse dependencies of Python won't be tested with new |
19 |
>> versions of Python. |
20 |
> |
21 |
> I don't see the problem here actually. As soon as you're going to allow |
22 |
> stable and unstable to be mixed, the concept of stable isn't worth much |
23 |
> any more, IMO. If you want to have some experimental feature in some |
24 |
> package, it can never be stable, unless it is e.g. USE-masked, and |
25 |
> unmasking of the right package(s) is left as an excercise for the |
26 |
> user. |
27 |
> |
28 |
> Your Python example only indicates to me how much of a mess it has |
29 |
> actually become. For most other packages, it is quite normal that a new |
30 |
> version is "untested" until it is stabilised, which means unstable users |
31 |
> are the ones to find the problems, if any. The maintainer (and to an |
32 |
> extent the arch teams) of course has a leading role in this. |
33 |
|
34 |
I think the "separate profiles for stable and unstable keywords" |
35 |
approach is a clear winner here. With separate stable and unstable |
36 |
profiles, unstable users don't have to do any unmasking themselves. When |
37 |
it comes time to migrate things to stable, the arch teams simply update |
38 |
the stable profiles to behave like the unstable profiles. This approach |
39 |
also protects stable users from experiencing "unsatisfied dependencies" |
40 |
that the *.unsatisfiable approach would expose them to. |
41 |
-- |
42 |
Thanks, |
43 |
Zac |