On Sunday 23 January 2005 09:45, Chris Frey wrote: > On Sat, Jan 22, 2005 at 04:16:34PM -0500, Chris Gianelloni wrote: > > Eclasses can never be removed from the tree. This is a fundamental > > truth of the current way things are done. No versioning will help this, > > but instead will just add more legacy crap in the tree that can *never* > > be removed. I don't want to have 85 versions of games.eclass in > > portage, which is how many we would have, given the cvs version of the > > eclass currently. Considering many of these were adding new > > functionality or bug fixing, this would be unacceptable. > > The fact that eclasses cannot be removed from the tree is important. > To my knowledge, I think they are not included in tbz2 binary packages > either, and yet sometimes the install depends on them.
Good point. So eclasses *must* be backward compatible for at least pkg_setup, pkg_preinst, pkg_postinst, pkg_prerm and pkg_postrm. > What I think would be very cool, and may somewhat relieve the perceived > need of versioned eclasses, is the ability to bundle the state of a package > at merge time. There is the ability to create binary packages, why not > "source seed packages"? This would include the ebuild, eclass, etc needed > to build anything at any time with a compatible version of portage. I was thinking along similar lines as well. An "ebuild compiler" should be able to solve all the issues related to *installing* old packages and users maintaining their own stabe tree. The backward compatibility requirements I stated above would still remain, however. Regards, Jason Stubbs -- [email protected] mailing list
