On Wed, Feb 16, 2005 at 11:54:47AM +0100, Gregorio Guidi wrote: > I think there's no need to keep it in the system default forever and to > suggest injecting it: it can be added to the system default for every > profile, and then removed starting from profile 200x.y. The profile updating > instructions will explain what will be the risk of removing it from the > system. Profiles won't work, allows for a possibility of people to miss the ebuild eclass-compat being pulled in. If someone doesn't upgrade for a long while, switches their profile (since it's now deprecated) to a new profile that lacks the eclass compat, they get left out in the rain.
After the old eclasses have been phased out of the tree, the only systems that are known to not require them is new bootstraps- so... add the eclass-compat requirement to profiles, and have the bootstrap script add a package.provided that blocks eclass-compat being pulled in. > > New eclasses and elib functionality will be tied to a specific portage > > version. A DEPENDs on said portage version should address this for rsync > > users who refuse to upgrade to a portage version that supports the new > > eclasses/elibs and will gradually be unable to merge ebuilds that use said > > functionality. > > Another possibility is to make this automatic: when creating the cache, > portage can recognize that new eclasses were used and add the > ">=sys-apps/portage-x.y" atom to DEPEND. Possible I spose, but I'm not much for adding basically a hack to portage :) I'd rather have it handled in the ebuilds, since theres no point in requiring a newer version of portage if the ebuild still uses the old eclasses (fex). ~brian -- [email protected] mailing list
