2010-12-18 03:48:26 Donnie Berkholz napisał(a): > On 02:45 Sat 18 Dec , Arfrever Frehtes Taifersar Arahesis wrote: > > Problem #1: USE flags cannot contain "." characters. > > This isn't a problem, it's an arbitrary statement of an antifeature. My > understanding of the actual problem here is that you want to have some > sort of USE flags for various Python versions with names containing > periods, for usability. Perhaps you could expand on exactly what you > want to do, so we can work together to figure out whether this is the > best route to solve your problem. > > If the problem is handling which Python versions to build modules for, > I'm wondering whether enhancing the eselect module to select multiple > preferred versions might not be a better solution than EAPI changes.
USE flags would allow to use USE dependencies to ensure that dependencies of given package have been installed for required Python versions. > > ================================================================================================ > > > > Problem #2: Files in profiles cannot use features from newer EAPIs. > > Could you explain how the eapi file in profiles does not address this? > The 10.0 profiles are using it already with EAPI=2. I would like to use EAPI="4"-specific syntax in a file in base profile (or somewhere else) to affect all profiles. If I have to rely on "eapi" files, then all non-deprecated profiles checked by repoman would have to use EAPI >=4. > > ================================================================================================ > > > > Problem #3: repoman doesn't allow stable packages to have optional > > dependencies on unstable > > packages (usually until these packages are stabilized). > > This seems useful at first glance, but I'm wondering how big of a > problem it really is and whether this solution is a bit overarchitected. > > > 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. > > Why does that have to be the case? Why not unmask them earlier but only > make them available to ~arch ebuilds? There are already hundreds of stable ebuilds, which support unstable Python 2.7 (without explicit optional dependency on Python 2.7). The solution to problem #3 shouldn't require any changes in ebuilds. > I don't know of anyone who's actually done this, but setting IUSE based > on ACCEPT_KEYWORDS being ~arch should be possible. It would break invariance of metadata. -- Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
