Re: [gentoo-portage-dev] [RFC] Mask packages that don't cross-compile

[Brian Harring]

On Wed, Nov 22, 2006 at 01:45:34PM -0500, Daniel Barkalow wrote:
> On Wed, 22 Nov 2006, Marius Mauch wrote:
>
> > No. -foo is reserved for incremental negation. Maybe that isn't widely
> > used in ACCEPT_KEYWORDS, but it has valid uses there and there can't be
> > repurposed.
>
> Oh, so -foo in package.keywords is used to override foo in
> ACCEPT_KEYWORDS?

Incremental negation; "x86 -x86" === ""

Haven't tried, but would suspect --x86 would come through as -x86 
(which annoyingly, is a valid keyword).

> That makes sense, although I'm not entirely convinced
> that the logic currently in there actually works. I think the actually
> effect seems to be that it lets you try to build a known-broken (for
> your arch) ebuild, even in the current trunk.

That's what -arch in package.keywords accomplishes actually.

> Both meanings make some
> sense, and I'm not clear why people would want to do either; I was just
> trying to be consistant with current behaviour.

> I think it's a legacy
> from using "-*" in packages to mask them, and "-*" in package.keywords to
> unmask packages masked this way.

The differing behaviour isn't legacy from package.mask; it's due to 
certain bad monkeys using -arch in KEYWORDS (a list of arches, 
*positive*, not negations) to overload it and indicate "this pkg will 
never work on arch foo".

And... just to make it a bigger mess, -* can (and is) jammed into 
keywords despite a repoman check bitching about it.  Folks use the 
tricks above as a 3rd level of visibility filtering (4th if you count 
accept_license); to use a pkg that has -*, have to stick -* in 
package.keywords to get at it, same for -arch.

Which... is bloody annoying.  ACCEPT_KEYWORDS is incremental, 
package.keywords isn't so that folks can get around the overloading 
people have done to pull off a 3rd level of visibility filtering.

What is annoying there is that since package.keywords is under 
*very* weird rules, you can't do the usual incremental tricks there.  

Try specifying that you want to run only stable arch via 
package.keywords sometime; it's not possible.


> > Is there a particular reason why you don't use the normal
> > keyword logic (KEYWORDS=cross and setting -cross in p.keywords to mask a
> > package), or simply a package.mask entry?
>
> I don't want to use a package.mask entry because then you'd need a profile
> for cross-compiling every current profile, and these would all have the
> same set of changes to the underlying profiles: mask packages that try to
> run the programs they build.
>
> I don't want to use ACCEPT_KEYWORDS=cross, because then I don't get only
> packages that are stable for my target architecture, and I want to use the
> normal package keyword information as to what versions are good for what
> architectures.
>
> Using ACCEPT_KEYWORDS="cross arm" (which might be what you're suggesting;
> portage would automatically insert "arm" if that's my target ARCH, so
> ACCEPT_KEYWORDS="cross" actually means ACCEPT_KEYWORDS="cross $ARCH")
> would be great, but that gives packages which have "arm" or "cross" (or
> "~arm" if I have that in package.keywords), when I want packages that have
> "arm" (or "cross", but they shouldn't) and don't have "-arm" (doesn't
> matter) or "-cross" (the important one).
>
> I.e., my only change is really to the situation where your keywords are
> "foo bar" and a package has "foo -bar". Currently, the package is not
> masked (because "foo" matches "foo"); I want it masked (because "bar"
> negatively matches "-bar"). (In fact, the current truck totally ignores
> "-bar" in a package's keywords, assuming that no package has "-bar" and
> either "bar" or "~bar" and that simply failing to match any keyword you
> have, since you won't have "-bar", is sufficient.)

And... that sucks imo.  :)

You're proposing further overloading of ACCEPT_KEYWORDS; how would 
this fly for package.keywords?

Alternative that comes to mind (and is cleaner) is to actually have 
portage *know* it's doing cross compilation; eliminates a fair bit of 
the nasty ROOT detection it has to do; that cleans up the innards a 
bit, but for it to work you would need a RESTRICT=cross-compile to 
mark packages that can't be x-compiled as unusable (yet another 
visibility filter, yay!) :)

Downside, such a restrict isn't fine grained per arch; pkg may 
cross-compile fine for arches running linux, but explode targettubg 
gfbsd for example.

My 2 cents at least.
~harring