| 1 |
Okay, here's a consolidation of the various comments about GLEP 22. |
| 2 |
|
| 3 |
The first comment, by Method, pointed out the most significant flaw in |
| 4 |
my proposal: the ARCH, LIBC, KERNEL, and USERLAND variables are not |
| 5 |
orthogonal (to use rac's term), so if ARCH lists x86 and ppc while |
| 6 |
KERNEL lists linux and obsd, how to we address the fact that obsd/ppc is |
| 7 |
not, in fact, a valid combination? |
| 8 |
|
| 9 |
I'm going to ignore a large thread of messages that discuss how |
| 10 |
sensitive alternative arch's are to requiring package patches to compile |
| 11 |
and/or function properly, other than to note that with the large number |
| 12 |
of possible ARCH/LIBC/KERNEL/USERLAND permutations even just enumerating |
| 13 |
the patches might end up being a tad hairy. There was also a thread |
| 14 |
suggesting that packages should not, in general, be marked stable unless |
| 15 |
it is supported on all archs (or whatever). |
| 16 |
|
| 17 |
Drake Wyrm noted that the proposed system allowed people to test new |
| 18 |
permutations that might just work. That sort of ability is something we |
| 19 |
should probably strive to maintain in whatever our ultimate solution |
| 20 |
should turn out to be. |
| 21 |
|
| 22 |
Rac has suggested a simple, if rather draconian, solution, which is to |
| 23 |
just let the explosion of keywords to occur, but get them out of the |
| 24 |
ebuilds. His suggestion is to provide a database (maintained external |
| 25 |
to the ebuilds, perhaps even external to the users' systems) that uses a |
| 26 |
five-dimensional (arch/os/libc/kernel/ebuild-version) key to determine |
| 27 |
whether or not an ebuild should be built. |
| 28 |
|
| 29 |
I would prefer a somewhat more elegant approach than rac's brute-force |
| 30 |
database, if I could only think of one. Any other thoughts out there? |
Archives