FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-23-2008, 11:53 PM
Robert Buchholz
 
Default Merging or overwriting KEYWORDS from eclass

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
 
Old 06-23-2008, 11:55 PM
Brian Harring
 
Default Merging or overwriting KEYWORDS from eclass

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
 
Old 06-24-2008, 10:05 AM
Tiziano Mller
 
Default Merging or overwriting KEYWORDS from eclass

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
 
Old 06-24-2008, 03:29 PM
Brian Harring
 
Default Merging or overwriting KEYWORDS from eclass

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
 
Old 06-24-2008, 05:32 PM
Peter Volkov
 
Default Merging or overwriting KEYWORDS from eclass

В Втр, 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
 

Thread Tools




All times are GMT. The time now is 08:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org