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

[Daniel Barkalow]

On Wed, 22 Nov 2006, Brian Harring wrote:

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

In any case, I'm not proposing any change to package.keywords or 
ACCEPT_KEYWORDS. Maybe I ought to, because the situation is confusing and 
some useful things aren't possible, but that's a separate issue.

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

I wouldn't change ACCEPT_KEYWORDS at all or anything in the computation of 
pgroups or mygroups in portdbapi.gvisible(), so package.keywords is 
unchanged and the whole incremental ACCEPT_KEYWORDS is also unchanged.

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.

> 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!) :)

I don't think adding a RESTRICT option that's a visibility filter, unlike 
all of the existing ones (which affect what steps in building a package 
portage can take), would clarify anything. Having portage automatically 
enable whatever visibility filter there is for ebuilds that don't 
cross-compile would be nice, but that's a separate step.

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

That's an issue with any proposal, but I bet that actually getting that 
level of details into ebuilds is going to be impractical anyway.

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-portage-dev@g.o mailing list