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

[Brian Harring]

On Wed, Nov 22, 2006 at 05:04:36PM -0500, Daniel Barkalow wrote:
> 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.

Find that a bit hard to believe frankly; inserting cross into a 
packages keywords _has_ to undergo the transformation somewhere.  If 
you're not doing it there, then you're probably doing it somewhere 
that you shouldn't be ;)


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

Not seeing how that proposal is related to xcompile either.


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

Well, the alternative is trying to shove (frankly) a hack into 
KEYWORDS.  KEYWORDS already has enough hacks in it, time to abuse 
another var ;)

Assuming marius does something with glep52, RESTRICT will be used as 
a visibility filter already for RESTRICT=unattended; long term 
intention for prefix support also (right now they're abusing eapi) 
was to control prefixability via a restrict also.

So... RESTRICT _is_ going to wind up being used for visibility.  The 
question (in my mind) is whether more tricks are going to be shoved 
into try and keep portage effectively unaware it's doing x-compile, or 
finally make it fully aware and bind the functionality folk need to 
that boolean.

~harring