| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 26/04/12 06:03 PM, Andreas K. Huettel wrote: |
| 5 |
> |
| 6 |
> Dear all, |
| 7 |
> |
| 8 |
> I'd like to suggest we introduce the following very useful feature, |
| 9 |
> as soon as possible (which likely means in the next EAPI?): |
| 10 |
> |
| 11 |
> * two new files in profile directories supported, |
| 12 |
> package.use.stable.mask and package.use.stable.force * syntax is |
| 13 |
> identical to package.use.mask and package.use.force * meaning is |
| 14 |
> identical to package.use.mask and package.use.force, except that |
| 15 |
> the resulting rules are ONLY applied iff a stable keyword is in |
| 16 |
> use |
| 17 |
> |
| 18 |
> Rationale: Often single features are "not ready for production |
| 19 |
> yet", but the remaining package with that feature disabled would be |
| 20 |
> a perfect candidate for stabilization. Right now this can be solved |
| 21 |
> by * masking the useflag, which then makes the feature inaccessible |
| 22 |
> even for ~arch * masking the useflag for exactly one package |
| 23 |
> revision, which is hell to maintain * or introducing different |
| 24 |
> package revisions with/without the useflag, which is also a mess. |
| 25 |
|
| 26 |
|
| 27 |
I would think, personally, that masking the useflag on a per-package |
| 28 |
basis would be better than this new feature -- it is more work as it |
| 29 |
needs to be done for all the different ~arch packages the use flag |
| 30 |
applies to, but it would mean that when a given ~arch version bump has |
| 31 |
that feature ready one wouldn't lose the mask on the previous ~arch |
| 32 |
versions. It would also mean (i assume) that this flag would be |
| 33 |
masked if that version went stable too (although in reality I would |
| 34 |
expect this wouldn't ever occur). |
| 35 |
|
| 36 |
There are potentially a lot of package entries to manage if this were, |
| 37 |
say, a flag like 'introspection'.. however, i'm sure maintaining this |
| 38 |
could be scriptable couldn't it? |
| 39 |
|
| 40 |
|
| 41 |
> |
| 42 |
> Where this would (have been|be) useful: * we had for a long time |
| 43 |
> different revisions of subversion with/without kde useflag * |
| 44 |
> cups-1.4 had the infamous libusb backend triggered by USE=usb * |
| 45 |
> cups-1.5 has optional systemd support via a systemd useflag, which |
| 46 |
> pulls in non-stabilized systemd as dependency... |
| 47 |
> |
| 48 |
|
| 49 |
I'm not sure that I'm following the cups examples here. For cups-1.5 |
| 50 |
even if it were stable, if someone actually wanted to use systemd on |
| 51 |
their system and unmasked/keyworded it (while running stable |
| 52 |
everything else) I don't see why this would be an issue that would |
| 53 |
need this new masking feature (unless IUSE="+systemd", which probably |
| 54 |
shouldn't be the case anyways). |
| 55 |
|
| 56 |
Ian |
| 57 |
-----BEGIN PGP SIGNATURE----- |
| 58 |
Version: GnuPG v2.0.17 (GNU/Linux) |
| 59 |
|
| 60 |
iF4EAREIAAYFAk+ara4ACgkQ2ugaI38ACPALZwD/bIk3GzOThs6P/2EkWn2DxvEY |
| 61 |
XHQZVUvmc1dJBERmSiIA/3saDFCoK79S8fw+2Q9Myf9Lt6PdEc4u1j48QcDf+sKW |
| 62 |
=XQ3/ |
| 63 |
-----END PGP SIGNATURE----- |
Archives