| 1 |
On Tue, Jun 24, 2008 at 12:05:39PM +0200, Tiziano M??ller wrote: |
| 2 |
> Brian Harring wrote: |
| 3 |
> |
| 4 |
> > On Tue, Jun 24, 2008 at 01:53:55AM +0200, Robert Buchholz wrote: |
| 5 |
> >> Hi, |
| 6 |
> >> |
| 7 |
> >> I've stumbled upon an inconsitency between package managers the other |
| 8 |
> >> day [1], which was due to both an ebuild and an eclass defining |
| 9 |
> >> inconsisting KEYWORDS. |
| 10 |
> >> |
| 11 |
> >> bla-1.ebuild: |
| 12 |
> >> inherit myeclass |
| 13 |
> >> KEYWORDS="~arch" |
| 14 |
> >> |
| 15 |
> >> myeclass.eclass: |
| 16 |
> >> KEYWORDS="arch" |
| 17 |
> >> |
| 18 |
> >> Portage will resolve this by overwriting the variable, so the last |
| 19 |
> >> (~arch) wins. Paludis, on the other hand, merges the variables, so it |
| 20 |
> >> is KEYWORDS="~arch arch". |
| 21 |
> >> |
| 22 |
> >> The PMS draft [2] defines that "IUSE, DEPEND, RDEPEND and PDEPEND" |
| 23 |
> >> variables be merged when defined in both eclass and ebuild (Section |
| 24 |
> >> 7.2), but only says "May be de?ned in an eclass" about KEYWORDS |
| 25 |
> >> (Section 8.2). |
| 26 |
> >> |
| 27 |
> >> Anyone up to toss a coin whose bug it is, and maybe we can have a more |
| 28 |
> >> specific wording in the PMS? |
| 29 |
> > |
| 30 |
> > Paludis bug; if you want KEYWORDS incremental, it'll need to be in |
| 31 |
> >>=eapi2, too nasty of a change to shoehorn into existing (in use) |
| 32 |
> > eapis. |
| 33 |
> well, if the PMS doesn't say anything about it, it's a lack of specification |
| 34 |
> and not a bug of a package manager. |
| 35 |
|
| 36 |
Falls to the same people regardless; in this case it is a bug of the |
| 37 |
manager since longstanding behaviour of keywords from eclasses has |
| 38 |
*always* been non-incremental. |
| 39 |
|
| 40 |
Regardless, omission of keywords from the list of incremental eclasses |
| 41 |
doesn't equate to "do what you want"- it means "it's not incremental". |
| 42 |
|
| 43 |
|
| 44 |
> Can you please give more info why this is "too nasty"? |
| 45 |
|
| 46 |
The original post gave an example of why this can't be shoehorned in- |
| 47 |
bla-1, instead of being marked unstable, becomes stable. I might add |
| 48 |
that it becomes stable effectively *always* also due to stable |
| 49 |
keywords existing in eclass. |
| 50 |
|
| 51 |
The use case for this isn't particularly grand either- the only real |
| 52 |
use case for such behaviour is shifting unstable keywords into the |
| 53 |
eclass, and storing the stable keywords in the ebuild. |
| 54 |
|
| 55 |
Problem with that however is that if a consumer of the eclass ever |
| 56 |
needs to be marked unusable (temporarily or otherwise) for a specific |
| 57 |
arch, the paludis keyword stacking means that the eclass would have to |
| 58 |
have that arch pruned from the eclass (sticking -$ARCH into the ebuild |
| 59 |
would most likely not suffice due to existing portage keyword |
| 60 |
visibility filters). |
| 61 |
|
| 62 |
Basically, if we were talking about tweaking IUSE, then I'd be singing |
| 63 |
a different tune- KEYWORDS behaviour, specifically keywords visibility |
| 64 |
filtering of available packages means that this isn't easily changable |
| 65 |
w/out resulting in past managers that worked properly, no longer |
| 66 |
working properly. |
| 67 |
|
| 68 |
For IUSE, you could likely get away with shoehorning this in- older |
| 69 |
managers generally didn't care much about IUSE (although |
| 70 |
built_with_use is a notable exception). |
| 71 |
|
| 72 |
Cheers. |
| 73 |
~brian |
Archives