| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Daniel Barkalow wrote: |
| 5 |
> On Tue, 28 Nov 2006, Zac Medico wrote: |
| 6 |
> |
| 7 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
| 8 |
>> Hash: SHA1 |
| 9 |
>> |
| 10 |
>> Daniel Barkalow wrote: |
| 11 |
>>> If the configuration has keywords "foo bar", and a package has "-foo |
| 12 |
>>> bar", mask the package ("masked by -bar keyword"). |
| 13 |
>>> |
| 14 |
>>> This is the sensible behavior if we ever make use of listing multiple |
| 15 |
>>> keywords in the configuration, which is currently implemented but not |
| 16 |
>>> used for anything. |
| 17 |
>> Personally, I'd prefer not to support -foo or -* in the KEYWORDS of |
| 18 |
>> an ebuild. For one thing, seems like it's trying to accomplish |
| 19 |
>> something similar to what package.mask is intended for. |
| 20 |
> |
| 21 |
> It's documented in the Ebuild HOWTO (at least, -foo). And the current |
| 22 |
> state is sort of broken: if you manage to get -foo in your |
| 23 |
> ACCEPT_KEYWORDS, you can build a known-broken package, but you can never |
| 24 |
> build a package that doesn't have -foo/~foo/foo. So you can only build a |
| 25 |
> package if you know it doesn't work. |
| 26 |
> |
| 27 |
> I'd say, make it impossible to set -foo (or -*) in ACCEPT_KEYWORDS. People |
| 28 |
> who want to build -foo packages can use * (or ~*) in their |
| 29 |
> package.keywords, which actually gives you the latest version that's |
| 30 |
> stable somewhere (or testing somewhere). |
| 31 |
|
| 32 |
Having -foo in ACCEPT_KEYWORDS is practically useless, and I think |
| 33 |
that alone is probably enough to constrain peoples behavior. Adding |
| 34 |
some code to explicitly prevent it seems redundant to me. |
| 35 |
|
| 36 |
> With my patch, you'd additionally need -foo in package.keywords to build a |
| 37 |
> -foo package, but then it means "don't worry about my foo keyword", which |
| 38 |
> is appropriate and really is the usual incremental stack thing. |
| 39 |
> |
| 40 |
> Incidently, I think with current trunk a package.keywords value of "-x86" |
| 41 |
> means "use an ebuild if and only if it is broken on x86", meaning that if |
| 42 |
> a newer version actually works, users using the broken version won't |
| 43 |
> upgrade. I bet that's not really what people want. |
| 44 |
|
| 45 |
The user can add "-x86 x86" to package.keywords if they want to |
| 46 |
accept both. |
| 47 |
|
| 48 |
>> Another problem is that is uses -foo and -* in completely different ways |
| 49 |
>> than they are used elsewhere in portage (for negation of values in |
| 50 |
>> an incremental stack). |
| 51 |
> |
| 52 |
> I think KEYWORDS (as opposed to ACCEPT_KEYWORDS) being thought of as an |
| 53 |
> incremental stack is sort of broken. (Not that it isn't done, but I think |
| 54 |
> that KEYWORDS in eclasses is just evil and generally wrong; check out |
| 55 |
> enlightenment.eclass and x11-wm/e/e-9999.ebuild for weird and wrong.) |
| 56 |
|
| 57 |
Yeah, KEYWORDS are supposed be directly in the ebuild so that arch |
| 58 |
teams have control over them for each individual ebuild. |
| 59 |
|
| 60 |
> But maybe !foo would be more appropriate anyway for "don't match if foo". |
| 61 |
> It might confuse people if what you do to unmask a "!foo" package is |
| 62 |
> "-foo *" (meaning "hide my foo keyword, match anything that works"), not |
| 63 |
> "!foo". Although I think the real way of unmasking these things should be |
| 64 |
> to put a modified version in your overlay. |
| 65 |
|
| 66 |
That would be really annoying if a user need to use an overlay just |
| 67 |
to keyword an ebuild. That's what package.keywords is for. |
| 68 |
|
| 69 |
Zac |
| 70 |
-----BEGIN PGP SIGNATURE----- |
| 71 |
Version: GnuPG v1.4.5 (GNU/Linux) |
| 72 |
|
| 73 |
iD8DBQFFcNzU/ejvha5XGaMRAmOkAKCSRGd+Gdwef1yRQ8OV/hA5K7yBZQCg2OW5 |
| 74 |
zEd2p2bT2kv5exGgxmUYZjg= |
| 75 |
=uu5H |
| 76 |
-----END PGP SIGNATURE----- |
| 77 |
-- |
| 78 |
gentoo-portage-dev@g.o mailing list |
Archives