On 25-03-2009 08:08:50 -0500, Jeremy Olexa wrote:
> > - "use <keyword> && bla" will no longer work (question; is it sane? well
> >   we need it in *DEPENDs at the moment for sure)
> 
> Reply to both you and mduft, same point.
> 
> The profile sets ARCH which is put into USE. so "use $ARCH && bla" will 
> still work.

If you say so, I haven't checked, so that would clear the issue at
least.

> > - Portage needs to be patched not to look at keywords any more, solar's
> 
> Set ACCEPT_KEYWORDS="**" in the profile, no patching needed.

Hmmm, it basically disables the entire capability.  Does that also
accept -arch?

> >   idea involved only having explicit -arch markings for stuff known not
> >   to compile/work
> 
> profile masking would also be equivalent.

That's than a "is it in our outside of the ebuild" thing, right?

> > - I don't like the idea:
> >> Before anyone says "but, that will be much more likely to break my 
> >> prefix" - I refute that because we are already running on this policy 
> >> with regards to the automatic bumps. For the most part, it is smooth. 
> >> Major packages are masked if someone hasn't tested them yet (eg. gcc & bash)
> >   Thing is here, that if you look at
> >   http://stats.prefix.freens.org/keywords-packages.png, you can clearly
> >   see a "gap" between x86-linux, and ppc-macos (the prefix leader in
> >   keyworded packages).  From an historical point of view, I'm almost
> >   sure this gap is largely consisting of broken packages for ppc-macos.
> 
> I'm not convinced. Nearly every package I add, I'm fairly sure would 
> work on macos these days.

I think you're optimistic ;)

> > - Last but not least, this proposal doesn't solve the keyword issue at
> >   all, it just introduces another hurdle; the change of keyword use.
> 
> We already operate in this fashion as pointed out with automatic version 
> bumps. (ie. xfce-4.6 still does not work but it was added to the tree - 
> both missing deps AND QA issues) - Over the last 2 days, I have been 
> reacting to it. Nothing was proactive anyway.

Well, of course you are right at this point.  And I largely rely on
other people fixing up my mess after a sync round next to myself.  I
know it frustrates some people, but doing a sync is very labour
intensive, and time consuming (have to say my two new disks in stripe
really help reducing the time consumption thing), and I can't bring it
up any more to check each and every thing I sync.

I think it especially becomes a mess when noone's around to fix, like
when both you and me are not around ;)  (Yes, it basically all just
depends on you and me...)

One big solution to this problem (me being sloppy when I sync) is when
we would go to gentoo-x86.  Keywords are an issue then, but we already
identified that Prefix keywords cannot be shared with gentoo-x86
keywords.  Luckily we made all of ours unique ;)  Suppose we would use
haubi style PREFIX_ACCEPT_KEYWORDS=... we would just be another line.
That said, now I think about it, our keywords, which differ from
gentoo-x86's ones, already mark an ebuild prefix ready.  So we could
start dropping EAPI="prefix", because the keywords just say it all...

For haubi-style ACCEPT_KEYWORDS we need a GLEP/proposal on gentoo-dev
for the next EAPI.
For implicit ACCEPT_KEYWORDS (like you/solari propose) we need a
GLEP/proposal on gentoo-dev to get that policy through.

In both cases, Prefix can adapt, but Prefix is not brought any closer to
gentoo-x86 IMO by using either of both proposals, since gentoo-x86
doesn't follow it!


-- 
Fabian Groffen
Gentoo on a different level