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. >From the user's point of view, there is only one way to completely guarantee that he can downgrade reliably, and that is to maintain his own history of the protage tree. I backup the entire tree before each sync myself, so I have a reliable history. Reliable downgrading is one half of the "holy grail" of package management, in my opinion (easy maintenance of simultaneous multiple versions of a software package is the other) and the farther you can go back into history, the better. So far, I don't think there is any distro that does it without placing a heavy burden on the user. The user either has to keep track of dependencies himself, or keep a history of binary packages, or keep source code around, or backup the portage tree, etc. 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. Such source seed packages wouldn't take a lot of space, and the space burden would be on the user, not the rsync infrastructor or the devs. Currently, I don't think eclasses are saved in the binary packages, which would be a useful addition. Thoughts? - Chris -- [email protected] mailing list
