1 |
On Wed, 25 Apr 2007 23:39:47 +0200 |
2 |
Rémi Cardona <remi@g.o> wrote: |
3 |
|
4 |
> Grant Goodyear a écrit : |
5 |
> > Fabian Groffen wrote: [Sat Apr 14 2007, 03:33:03AM CDT] |
6 |
> >> For people that like reading it in html or via the web: |
7 |
> >> http://dev.gentoo.org/~grobian/gleps/glep-keywords.html |
8 |
> >> http://dev.gentoo.org/~grobian/gleps/glep-keywords.txt |
9 |
> > |
10 |
> > So what would a version of Gentoo for amd64 based on FreeBSD but |
11 |
> > using glibc be called? (It's not an entirely academic question; |
12 |
> > Debian folks have worked on such a distribution for some time.) |
13 |
> > I can't really tell from the text in your proposed GLEP. |
14 |
> |
15 |
> I'm sure this GLEP can be extended later on should anyone feel like |
16 |
> doing a glibc-based freebsd port of gentoo (hurts my brains just |
17 |
> writing this :) ) |
18 |
|
19 |
I think it will be better if this scheme is specified in friendlier |
20 |
way for future expansions, hence I this it should be more flexible. |
21 |
|
22 |
I would propose this two modifications: |
23 |
|
24 |
(a) Instead of using n-tuples to describe a keyword, to use sets. |
25 |
|
26 |
Both ways can be made semantically equivalent if we add the |
27 |
restrictions that the sets of all the possible architecture, kernel, |
28 |
userland, libc, ... sub-keywords are disjoint. (i.e. If there is a |
29 |
userland sub-keyword bsd, then there can't be a kernel or libc |
30 |
sub-keyword named bsd, they have to be named in a slightly different |
31 |
way.) |
32 |
|
33 |
But on the other hand, the notation will be way more flexible as a |
34 |
keyword can only specify the relevant sub-keywords, while the rest can |
35 |
be considered to be a wildcard (to mean "all") |
36 |
|
37 |
(b) In case there are several keywords A and B: |
38 |
- if A is more specific that B, A takes precedence (ej. with "!uclibc |
39 |
arm:uclibc" the package can be installed on any system that does not |
40 |
uses uclibc as libc or on any system with arm hardware.) |
41 |
- if A is exactly as specific as B, the union of A and B is used (ej. |
42 |
"!uclibc arm" this is equivalent to the previous example.) |
43 |
|
44 |
So to give more examples, |
45 |
|
46 |
A package that can only be build on arm, sparc and x86 with linux and |
47 |
glibc or arm with uclibc can be specified as: |
48 |
"{arm,sparc,x86}:linux:glibc arm:uclibc" |
49 |
|
50 |
A package (lets say linux-headers) that makes sense on all systems that |
51 |
support linux and only them can be specified as: |
52 |
"linux" |
53 |
|
54 |
A package that is stable with gnu userland but still in testing with |
55 |
bsd userland: |
56 |
"{some,arches}:gnu ~{some,arches}:bsd" or just "gnu ~bsd" for all |
57 |
arches. |
58 |
|
59 |
Note that I propose to mark testing the whole set of sub-keywords, not |
60 |
just like I run stable x86 with unstable bsd as I think it does not make |
61 |
any sense as the resulting combination is still considered |
62 |
unstable/testing. |
63 |
|
64 |
There are two things I see against my proposal: |
65 |
- This is not fully backward compatible, as it is currently equivalent |
66 |
to normal arch keywords if the user runs linux with glibc/uclibc, |
67 |
while it has a completely different meaning for Gentoo/Alt users. |
68 |
But I don't see it as a big problem because, as far as I understand, |
69 |
this will be just one of many changes that need to be made to make |
70 |
Gentoo/Alt as integrated as GNU/Linux is now into portage. |
71 |
|
72 |
- For this to work, the keyword resolver will have to be way more |
73 |
complex than it is now, as it will have to compute the subset of all |
74 |
possible keywords some ebuild defines to see if user's accept |
75 |
keywords intersect it. |
76 |
|
77 |
Kindest regards, |
78 |
Yuri. |
79 |
-- |
80 |
gentoo-dev@g.o mailing list |