On Tue, 20 Feb 2007 14:12:12 -0700 "Daniel Robbins" <[EMAIL PROTECTED]> wrote: | 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."
Yep. Here's the problem though: How much of the tree is it ok to modify, and how complex are the modifications allowed to be, for the sake of compatibility? The aim with Paludis is to ask for modifications only where it's a hard dried "the ebuild / eclass is doing something highly stupid", simply because that's the only way it will be accepted. Even then, some maintainers refuse to make changes to code that works with one particular version of Portage. And until PMS is standardised, there's nothing that can be done to make them do otherwise. | 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. In principle, I agree. In practice, writing robust bash code is a pain in the ass. If it's the case of a couple of lines of hacks in the package manager or a dozen lines of hacks in hundreds of ebuilds, it's simply more practical to impose a weird requirement upon the package manager. | 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. Eh, my objections to eclasses are purely based upon the limitations imposed by Portage (the "no API change" one). As a general idea they make the tree a lot less complex, and they often move all the package manager dependent hacks into one place... | If you wanted to get me to agree with you by giving me lots of eclass | compatibility issues, then it worked :) Hm. Maybe I should have picked up some of the dodgy ebuild code instead... There's a heck of a lot of that too. It's just that eclass weirdness is easier to find. -- Ciaran McCreesh Mail : ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
