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