OK, my initial impression of this is:
1) ebuilds and *especially* eclasses do way too many weird things and
can often depend on idiosyncrasies of portage. The eclass bash scripts
can be quite complex and probably 9 out of 10 (99 out of 100?) times
I'd put the burden of compatibility on the eclass rather than the
package manager, because it's the eclass that's trying to do "weird
stuff."
2) to ensure cross-package-manager compatibility, all one would need
to do is document what one can and cannot assume regarding Portage
functionality. I see no harm in having the ebuilds/eclasses assume
less and encourage others to write more robust and compatible ebuild
and eclass functions.
3) I regretfully added eclasses to portage. Although they're useful, I
don't think they ever made sense from an architecture perspective and
are certainly not pretty. Eclasses are nearly ubiquitous now, which is
unfortunate. I can't remember seeing an eclass that I ever liked, even
if the functionality was really useful and everything was
well-written, thought out, documented, etc.
4) Building on 3, I think there are two ways of life in the world of
Portage - either the eclasses control you, or you fight back a bit and
control the growth of eclasses. The eclasses are sort of an
"anti-architecture" so I think our will should to be imposed on them
rather than the other way around. Otherwise you are in a catch-22
where we are continually adding tons of weird "legacy code" in the
form of eclasses and this problem of cross-package manager
compatibility will never go away.
Those are my thoughts, anyway...
If you wanted to get me to agree with you by giving me lots of eclass
compatibility issues, then it worked :)
-Daniel
On 2/20/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
On Tue, 20 Feb 2007 12:19:12 -0700 "Daniel Robbins"
<[EMAIL PROTECTED]> 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/
--
gentoo-dev@gentoo.org mailing list
