On Tue, Jun 24, 2008 at 12:05:39PM +0200, Tiziano M??ller wrote: > Brian Harring wrote: > > > On Tue, Jun 24, 2008 at 01:53:55AM +0200, Robert Buchholz wrote: > >> Hi, > >> > >> I've stumbled upon an inconsitency between package managers the other > >> day [1], which was due to both an ebuild and an eclass defining > >> inconsisting KEYWORDS. > >> > >> bla-1.ebuild: > >> inherit myeclass > >> KEYWORDS="~arch" > >> > >> myeclass.eclass: > >> KEYWORDS="arch" > >> > >> Portage will resolve this by overwriting the variable, so the last > >> (~arch) wins. Paludis, on the other hand, merges the variables, so it > >> is KEYWORDS="~arch arch". > >> > >> The PMS draft [2] defines that "IUSE, DEPEND, RDEPEND and PDEPEND" > >> variables be merged when defined in both eclass and ebuild (Section > >> 7.2), but only says "May be de?ned in an eclass" about KEYWORDS > >> (Section 8.2). > >> > >> Anyone up to toss a coin whose bug it is, and maybe we can have a more > >> specific wording in the PMS? > > > > Paludis bug; if you want KEYWORDS incremental, it'll need to be in > >>=eapi2, too nasty of a change to shoehorn into existing (in use) > > eapis. > well, if the PMS doesn't say anything about it, it's a lack of specification > and not a bug of a package manager.
Falls to the same people regardless; in this case it is a bug of the manager since longstanding behaviour of keywords from eclasses has *always* been non-incremental. Regardless, omission of keywords from the list of incremental eclasses doesn't equate to "do what you want"- it means "it's not incremental". > Can you please give more info why this is "too nasty"? The original post gave an example of why this can't be shoehorned in- bla-1, instead of being marked unstable, becomes stable. I might add that it becomes stable effectively *always* also due to stable keywords existing in eclass. The use case for this isn't particularly grand either- the only real use case for such behaviour is shifting unstable keywords into the eclass, and storing the stable keywords in the ebuild. Problem with that however is that if a consumer of the eclass ever needs to be marked unusable (temporarily or otherwise) for a specific arch, the paludis keyword stacking means that the eclass would have to have that arch pruned from the eclass (sticking -$ARCH into the ebuild would most likely not suffice due to existing portage keyword visibility filters). Basically, if we were talking about tweaking IUSE, then I'd be singing a different tune- KEYWORDS behaviour, specifically keywords visibility filtering of available packages means that this isn't easily changable w/out resulting in past managers that worked properly, no longer working properly. For IUSE, you could likely get away with shoehorning this in- older managers generally didn't care much about IUSE (although built_with_use is a notable exception). Cheers. ~brian
pgp9ke0PHjt3J.pgp
Description: PGP signature
