1 |
On Fri, 02 Jun 2006 16:17:06 +0000 |
2 |
Ferris McCormick <fmccor@g.o> wrote: |
3 |
|
4 |
> Grant, |
5 |
> Apologies; I can't find your note from yesterday, so I can't respond |
6 |
> to the correct topic. |
7 |
> One question just occurred to me; if it's been addressed before, |
8 |
> apologies about that, too. Your requirement that any alternative |
9 |
> package manager support any ebuild which portage supports seems |
10 |
> essential, except for a boundary case. What about ebuilds which for |
11 |
> whatever reason are invalid (serious specification violation, for |
12 |
> example, to the extent that QA would reject them), but portage accepts |
13 |
> them anyway. Must the alternative accept them as well? In a case |
14 |
> like this, it seems to me that the ebuild works because of a bug in |
15 |
> portage, and there should be no complaint if as a side effect of |
16 |
> fixing this bug the ebuild in question quit working. |
17 |
> If memory serves me, things like this have indeed happened. I can't |
18 |
> recall a specific, however. |
19 |
|
20 |
Actually this is probably the main problem of all the "package manager |
21 |
compability" gleps: We don't have a proper specification, all existing |
22 |
docs more or less are based on the existing portage implementation. So |
23 |
right now the implementation is the authorative specification, which of |
24 |
course creates some problems. |
25 |
IMO before any such glep can be considered we need a proper |
26 |
specification about our package and repository formats, otherwise you |
27 |
can't really validate any package manager (the statespace is a bit |
28 |
large for equivalence checks). |
29 |
|
30 |
Marius |
31 |
|
32 |
-- |
33 |
Public Key at http://www.genone.de/info/gpg-key.pub |
34 |
|
35 |
In the beginning, there was nothing. And God said, 'Let there be |
36 |
Light.' And there was still nothing, but you could see a bit better. |
37 |
-- |
38 |
gentoo-dev@g.o mailing list |