| 1 |
On 02:45 Sat 18 Dec , Arfrever Frehtes Taifersar Arahesis wrote: |
| 2 |
> Problem #1: USE flags cannot contain "." characters. |
| 3 |
|
| 4 |
This isn't a problem, it's an arbitrary statement of an antifeature. My |
| 5 |
understanding of the actual problem here is that you want to have some |
| 6 |
sort of USE flags for various Python versions with names containing |
| 7 |
periods, for usability. Perhaps you could expand on exactly what you |
| 8 |
want to do, so we can work together to figure out whether this is the |
| 9 |
best route to solve your problem. |
| 10 |
|
| 11 |
If the problem is handling which Python versions to build modules for, |
| 12 |
I'm wondering whether enhancing the eselect module to select *multiple* |
| 13 |
preferred versions might not be a better solution than EAPI changes. |
| 14 |
|
| 15 |
We've been having the same discussion for Fortran90 modules, and George |
| 16 |
Shapovalov mentioned that this is how he handled things for Ada (see |
| 17 |
gnat-related eclass/eselect mod). |
| 18 |
|
| 19 |
> ================================================================================================ |
| 20 |
> |
| 21 |
> Problem #2: Files in profiles cannot use features from newer EAPIs. |
| 22 |
|
| 23 |
Could you explain how the eapi file in profiles does not address this? |
| 24 |
The 10.0 profiles are using it already with EAPI=2. I'll paste the |
| 25 |
description from the PMS to make it easier for anyone following along: |
| 26 |
|
| 27 |
5.2.2 The eapi file |
| 28 |
|
| 29 |
A profile directory may contain an eapi file. This file, if it exists, |
| 30 |
must contain a single line with the name of an EAPI. This specifies the |
| 31 |
EAPI to use when handling the directory in question; a package manager |
| 32 |
must not attempt to use any profile using a directory which requires an |
| 33 |
EAPI it does not support. If no eapi file is present, EAPI 0 shall be |
| 34 |
used. The EAPI is not inherited via the parent file. |
| 35 |
|
| 36 |
> ================================================================================================ |
| 37 |
> |
| 38 |
> Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable |
| 39 |
> packages (usually until these packages are stabilized). |
| 40 |
|
| 41 |
This seems useful at first glance, but I'm wondering how big of a |
| 42 |
problem it really is and whether this solution is a bit overarchitected. |
| 43 |
|
| 44 |
> Example of the problem: |
| 45 |
> If "python_abis_2.7", "python_abis_3.1" and "python_abis_3.2" USE |
| 46 |
> flags are masked using use.mask on given architectures until Python |
| 47 |
> 2.7, 3.1 and 3.2 are stabilized on these architectures, then majority |
| 48 |
> of reverse dependencies of Python won't be tested with new versions of |
| 49 |
> Python. |
| 50 |
|
| 51 |
Why does that have to be the case? Why not unmask them earlier but only |
| 52 |
make them available to ~arch ebuilds? |
| 53 |
|
| 54 |
I don't know of anyone who's actually done this, but setting IUSE based |
| 55 |
on ACCEPT_KEYWORDS being ~arch should be possible. There may be better |
| 56 |
or easier solutions. |
| 57 |
|
| 58 |
> The following solutions have been suggested: |
| 59 |
> |
| 60 |
> - Add support for use.unsatisfiable and package.use.unsatisfiable files in profiles in |
| 61 |
> EAPI="4". These files would cause that repoman would allow optional |
| 62 |
> dependencies on packages potentially unsatisfiable in some |
| 63 |
> configurations (e.g. on stable-only systems). |
| 64 |
> - Create separate profiles for stable and unstable keywords. USE flags |
| 65 |
> would be masked in stable profiles and unmasked in unstable profiles. |
| 66 |
> |
| 67 |
> Council should choose one of these solutions. |
| 68 |
|
| 69 |
-- |
| 70 |
Thanks, |
| 71 |
Donnie |
| 72 |
|
| 73 |
Donnie Berkholz |
| 74 |
Sr. Developer, Gentoo Linux |
| 75 |
Blog: http://dberkholz.wordpress.com |
Archives