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

[Brian Harring]

On Wed, Nov 22, 2006 at 07:27:42PM -0500, Daniel Barkalow wrote:
> On Wed, 22 Nov 2006, Brian Harring wrote:
> I'm not inserting cross into a package's keywords. I'm saying that perl
> ebuilds (for example) should have in their KEYWORDS "-cross" to indicate
> that they don't work with the "cross" keyword. The logic is the completely
> universal thing where a package puts its keywords in KEYWORDS, and the
> configuration has keywords in make.conf. The proper place for an ebuild to
> specify that it doesn't work when cross-compiling is, obviously, in the
> ebuild, since the maintainers obviously know, or can be told.
>
> With mainline emerge (and a locally-modified perl ebuild that adds
> "-cross" to KEYWORDS) and ACCEPT_KEYWORDS="cross", I get:
>
> mygroups = "alpha amd64 arm hppa ia64 m68k mips ppc ~ppc-macos ppc64 s390
>  sh sparc ~sparc-fbsd x86 ~x86-fbsd -cross"
> pgroups = "arm cross"

Stand corrected, although would probably take an act of god for me to 
consider KEYWORDS='* -x86' being matched by ACCEPT_KEYWORDS=x86 
anything but an oddity of the implementation ;)


> > > The present documentation (Ebuild HOWTO, for example) says "If the
> > > KEYWORDS flag has a preceding -, then the package does not work with the
> > > given keyword." But this is ignored by portage, because "Packages that do
> > > not support the native architecture are automatically masked by Portage",
> > > which means that "-x86" has no effect, because an ebuild with "-x86" won't
> > > have "x86" or "~x86", and is therefore masked. I'm proposing that "-foo"
> > > be taken seriously as meaning that the package does not work with the
> > > "foo" keyword, even if the ebuild would otherwise be visible.
> >
> > Why would you propose that?  That's already the case as is, folks just
> > have a way around it if they try hard enough (which isn't necessarily
> > a bad thing).
>
> That is not the case currently. If a package has "-foo" (when the user has
> "foo" and doesn't have "-foo"), the ebuild still can pass the keyword
> check. E.g., if an ebuild has KEYWORDS="* -x86", it will be built on x86.

Statement above is still the case; for '*', that's a *very* odd case, 
one that's not relevant either- no ebuild has '*' for a keyword token, 
and any dev commiting such an attrocity would likely be flogged 
publically.


> In the example above, the package is not masked under the current
> implementation, because "arm" matches and "-cross" is completely ignored.

As stated, '*' is never used, and *will* never be used; there isn't 
any justification for it nor previous usage of it in the 3+ years or 
so I've been around (and annoying folk).


> > Not seeing how that proposal is related to xcompile either.
>
> It's not specificly connected to xcompile. It just lets ebuilds specify
> negative keywords that have actual effects.

Offhand, why should keywords be _able_ to be negative?  KEYWORDS is 
just a list of elements that keywords visibility must match, treated 
(now even) as just positives/assertions for arches; -arch in KEYWORDS 
is currently just storing intent/notes (effectively) in KEYWORDS, the 
fact folks can match against it is an oddity from package.keywords, a 
sideaffect of disabling incrementals for package.keywords so that 
people could get at -* keyworded ebuilds;

-* already is flagged as bad in an ebuild; iow, it's likely to die 
off... so why expand it?

Additional question is if -arch isn't related to xcompile, why 
should the change be made if nothing needs it? :)


> It's just that "I'm
> cross-compiling" is a property that isn't tied to a particular profile and
> which a number of ebuilds could use to say "this ebuild won't work for
> you".

So why abuse keywords for it, when restrict exists?  Keywords has a 
specific purpose now, it's not used to store bools for random 
capabilities (one could argue that archs are just that, but that's a 
bit of a reach).

That said, RESTRICT *is* used to store random bools for capabilities; 
why do you think keywords should be adjusted in scope when RESTRICT 
has historically served as a dumping ground for bits like this?

~harring