[gentoo-dev] Merging or overwriting KEYWORDS from eclass

[gentoo-dev] Merging or overwriting KEYWORDS from eclass

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

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 defined 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?


Robert

[1] http://trac.pioto.org/paludis/ticket/586#comment:10
[2] http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [gentoo-dev] Merging or overwriting KEYWORDS from eclass

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

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 defined 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.

Cheers,
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Merging or overwriting KEYWORDS from eclass

[Tiziano Müller]

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.

hmm, the program you use for posting should really have a delay function in
case you respond too fast (1:25 according to my news reader, gmane and the
assumption clocks are in sync).

well, if the PMS doesn't say anything about it, it's a lack of specification
and not a bug of a package manager.

Can you please give more info why this is "too nasty"?

Cheers,
Tiziano


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Merging or overwriting KEYWORDS from eclass

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Merging or overwriting KEYWORDS from eclass

[Peter Volkov]

В Втр, 24/06/2008 в 01:53 +0200, Robert Buchholz пишет:
> 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.

But do we allow KEYWORDS in eclasses? Why? Each package should be tested
independently on each arch and there is no sane way to test all ebuilds
that inherit eclass... Or do we have exceptions? If so, then ebuilds for
dictionaries and stardict.eclass could be perfect exception, but QA team
prohibited usage of KEYWORDS in stadict eclass. See bug 163833 .

-- 
Peter.

-- 
gentoo-dev@lists.gentoo.org mailing list