1 |
On Tue, 20 Feb 2007 12:19:12 -0700 "Daniel Robbins" |
2 |
<drobbins.daniel@×××××.com> wrote: |
3 |
| I think that standardization is a good thing and interoperability |
4 |
| between paludis, portage, pkgcore and others is something we should |
5 |
| strive for. If at all possible, I think that this standardization |
6 |
| effort should be "multi-lateral" in the sense that Gentoo and pkgcore |
7 |
| are also active participants in the standardization process. |
8 |
|
9 |
Well, Gentoo already is a participant, in that there are a number |
10 |
of Gentoo developers with access to the document... At this stage, we're |
11 |
deliberately keeping the numbers down because we want to get it done |
12 |
rather than spend huge amounts of time arguing with the peanut gallery |
13 |
(the same approach we took with eselect, the devmanual and Paludis, |
14 |
rather than the approach taken with portage-ng and Zynot). |
15 |
|
16 |
| Also, I don't think that the council itself needs to be involved |
17 |
| directly, as a standards/spec project can be created and worked on, |
18 |
| and the conformance of Portage to this standard can be measured, and |
19 |
| if desired Portage developers can tweak portage so that it is more |
20 |
| conformant to this standard. This can be done voluntarily by all |
21 |
| parties, as they deem it useful. |
22 |
|
23 |
The reason the Council is involved is because someone has to give final |
24 |
approval. This won't be asked for until late on in the process. |
25 |
|
26 |
| I think standardization should focus on real interoperability issues, |
27 |
| rather than esoteric technical issues. |
28 |
|
29 |
The esoteric technical issues are the problem, though. The areas where |
30 |
there are interoperability problems are the areas where ebuilds are |
31 |
doing weird things, like relying upon side effects of one |
32 |
implementation of inherit or trying to manually modify vdb or assuming |
33 |
that certain variables that contain directory names will not include a |
34 |
trailing slash. The question is whether the ebuilds are wrong in |
35 |
expecting to be able to do this, or whether package managers have to |
36 |
emulate weird quirks in how Portage is currently implemented. |
37 |
|
38 |
I'll give you a perfect example. Paludis currently includes the |
39 |
following workaround: |
40 |
|
41 |
archives = strip_trailing(archives, " "); |
42 |
all_archives = strip_trailing(all_archives, " "); |
43 |
|
44 |
The reason that this is necessary is because kde-meta.eclass does this: |
45 |
|
46 |
[[ -n ${A/${TARBALL}/} ]] && unpack ${A/${TARBALL}/} |
47 |
|
48 |
Which means that if a package manager includes trailing spaces in ${A}, |
49 |
the eclass will break. Personally I consider this to be an eclass bug, |
50 |
but without some standard to back it up there's no concrete answer |
51 |
either way. |
52 |
|
53 |
Another example along the same lines (this one's now fixed in the tree, |
54 |
but it's a good example of weird side effect behaviour): The PHP |
55 |
eclasses used to set a global scope variable called EXT_DIR based upon |
56 |
the value of a variable called PHPCONFIG. The PHPCONFIG variable was |
57 |
set in pkg_setup, and the EXT_DIR variable was used later on. For |
58 |
Portage as it is currently implemented, this happens to be ok, because |
59 |
eclasses are re-sourced for every phase. For Paludis this breaks, |
60 |
because we implement the environment saving that Portage is going to do |
61 |
at some point to avoid the eclass API problems. |
62 |
|
63 |
Another example: A certain eclass we all know and love used to use |
64 |
SLOT=${PVR} and then force uninstalls by overwriting VDB SLOT files |
65 |
when installing packages. As it happens, Portage doesn't cache those |
66 |
entries, and because of how it implements cleaning the hack happens to |
67 |
work. The question is whether ebuilds are allowed to rely upon weird |
68 |
quirks like that (and, indeed, whether ebuilds should be reading VDB at |
69 |
all). |
70 |
|
71 |
Another example: Various ebuilds rely upon the order of items in $A |
72 |
matching the order in $SRC_URI. This one's arguably useful, but at the |
73 |
same time it's questionable as to whether it works by fluke. |
74 |
|
75 |
It's these cases that are the problem, not the generalities. On the one |
76 |
hand, requiring that package managers implement every Portage quirk |
77 |
identically is insane, and stops Portage from changing behaviour in the |
78 |
future. On the other hand, restricting the API to only completely sane |
79 |
things makes it much harder to code certain ebuilds -- the $A ordering |
80 |
is one example of this. |
81 |
|
82 |
-- |
83 |
Ciaran McCreesh |
84 |
Mail : ciaranm at ciaranm.org |
85 |
Web : http://ciaranm.org/ |
86 |
Paludis, the secure package manager : http://paludis.pioto.org/ |