1 |
On 25-03-2009 08:08:50 -0500, Jeremy Olexa wrote: |
2 |
> > - "use <keyword> && bla" will no longer work (question; is it sane? well |
3 |
> > we need it in *DEPENDs at the moment for sure) |
4 |
> |
5 |
> Reply to both you and mduft, same point. |
6 |
> |
7 |
> The profile sets ARCH which is put into USE. so "use $ARCH && bla" will |
8 |
> still work. |
9 |
|
10 |
If you say so, I haven't checked, so that would clear the issue at |
11 |
least. |
12 |
|
13 |
> > - Portage needs to be patched not to look at keywords any more, solar's |
14 |
> |
15 |
> Set ACCEPT_KEYWORDS="**" in the profile, no patching needed. |
16 |
|
17 |
Hmmm, it basically disables the entire capability. Does that also |
18 |
accept -arch? |
19 |
|
20 |
> > idea involved only having explicit -arch markings for stuff known not |
21 |
> > to compile/work |
22 |
> |
23 |
> profile masking would also be equivalent. |
24 |
|
25 |
That's than a "is it in our outside of the ebuild" thing, right? |
26 |
|
27 |
> > - I don't like the idea: |
28 |
> >> Before anyone says "but, that will be much more likely to break my |
29 |
> >> prefix" - I refute that because we are already running on this policy |
30 |
> >> with regards to the automatic bumps. For the most part, it is smooth. |
31 |
> >> Major packages are masked if someone hasn't tested them yet (eg. gcc & bash) |
32 |
> > Thing is here, that if you look at |
33 |
> > http://stats.prefix.freens.org/keywords-packages.png, you can clearly |
34 |
> > see a "gap" between x86-linux, and ppc-macos (the prefix leader in |
35 |
> > keyworded packages). From an historical point of view, I'm almost |
36 |
> > sure this gap is largely consisting of broken packages for ppc-macos. |
37 |
> |
38 |
> I'm not convinced. Nearly every package I add, I'm fairly sure would |
39 |
> work on macos these days. |
40 |
|
41 |
I think you're optimistic ;) |
42 |
|
43 |
> > - Last but not least, this proposal doesn't solve the keyword issue at |
44 |
> > all, it just introduces another hurdle; the change of keyword use. |
45 |
> |
46 |
> We already operate in this fashion as pointed out with automatic version |
47 |
> bumps. (ie. xfce-4.6 still does not work but it was added to the tree - |
48 |
> both missing deps AND QA issues) - Over the last 2 days, I have been |
49 |
> reacting to it. Nothing was proactive anyway. |
50 |
|
51 |
Well, of course you are right at this point. And I largely rely on |
52 |
other people fixing up my mess after a sync round next to myself. I |
53 |
know it frustrates some people, but doing a sync is very labour |
54 |
intensive, and time consuming (have to say my two new disks in stripe |
55 |
really help reducing the time consumption thing), and I can't bring it |
56 |
up any more to check each and every thing I sync. |
57 |
|
58 |
I think it especially becomes a mess when noone's around to fix, like |
59 |
when both you and me are not around ;) (Yes, it basically all just |
60 |
depends on you and me...) |
61 |
|
62 |
One big solution to this problem (me being sloppy when I sync) is when |
63 |
we would go to gentoo-x86. Keywords are an issue then, but we already |
64 |
identified that Prefix keywords cannot be shared with gentoo-x86 |
65 |
keywords. Luckily we made all of ours unique ;) Suppose we would use |
66 |
haubi style PREFIX_ACCEPT_KEYWORDS=... we would just be another line. |
67 |
That said, now I think about it, our keywords, which differ from |
68 |
gentoo-x86's ones, already mark an ebuild prefix ready. So we could |
69 |
start dropping EAPI="prefix", because the keywords just say it all... |
70 |
|
71 |
For haubi-style ACCEPT_KEYWORDS we need a GLEP/proposal on gentoo-dev |
72 |
for the next EAPI. |
73 |
For implicit ACCEPT_KEYWORDS (like you/solari propose) we need a |
74 |
GLEP/proposal on gentoo-dev to get that policy through. |
75 |
|
76 |
In both cases, Prefix can adapt, but Prefix is not brought any closer to |
77 |
gentoo-x86 IMO by using either of both proposals, since gentoo-x86 |
78 |
doesn't follow it! |
79 |
|
80 |
|
81 |
-- |
82 |
Fabian Groffen |
83 |
Gentoo on a different level |