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