On Fri, 16 Mar 2007 00:36:49 +0000 Steve Long <[EMAIL PROTECTED]> wrote: > Stephen Bennett wrote: > >> My understanding was that the portage team can't move forward with > >> a new version until EAPI0 is done? > > They can't move forward with changes that break ebuild compatibility > > until EAPI-0 is documented and EAPI-1 can start to be defined. > > That's not to say that user-side changes which don't affect the > > ebuild interface can't happen. > Ah ok. > Well, given the state of the portage code, I doubt it's worth > starting anew until EAPI0 is done, since clearly the team have to do > maintenance and improvements in the meanwhile, as so many ppl depend > on portage working right.
A good design won't be strongly tied in to any particular EAPI related information. It should be easy to make any sane changes required for future EAPIs. Any rewrite that fails in this requirement will just run into the same problems later on. That is, of course, vague, fuzzy and unquantifiable. Some things are like that. As a simple test for this, adding support for another package format seems to be a good start... GNU CRAN is the route Paludis happened to take first, partly because someone wanted it and partly because CPAN is inconsistent and poorly documented... Point is, if your package manager has no problems introducing a completely new format, it likely won't have problems with EAPI changes. (Now, as a design issue, whether that means making everything fully replaceable from the start or making sane things replaceable possible with core code changes as appropriate is up for debate, and probably depends more upon language features like static checking than anything else... In any case, starting out as a wrapper for ebuilds is what led to Portage's current state -- it was fine for its original purpose, but not much else.) > Also, I thought one of the main benefits was making things easier for > ebuild devs? Ciaran was himself disdainful of UI improvements. There's a difference between UI improvements like FEATURES=candy and UI improvements like ability to do dependency-based uninstalls (merely one example). UI improvements that improve user experience substantially are fine. Minor UI improvements are good too, but not when they're being touted as significant achievements. -- 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
