On Wednesday 16 February 2005 10:47, Brian Harring wrote: > On Wed, Feb 16, 2005 at 10:39:33AM +0100, Luca Barbato wrote: > > John Mylchreest wrote: > > >All comments or criticisms are more than welcome. > > >Please let me know what your thoughts are. > > > > looks interesting and not particulary painful to implement. > > Nope, pretty straightforward- the portage side of it is pretty minor.
That's an excellent GLEP, well thought and well written, I hope to see it implemented soon. > Just need feedback from eclass devs that A) the switchover proposed would > work for them, B) no naggles with the proposal, C) any *possible* > additions. A couple comments: > It's advisable that once all old eclasses are no longer in use in the tree, > the old eclass package is added to system default. Remember that even > those who have upgraded to a portage version that handles the env correctly, > may run into > instances where an installed packages env is corrupt. For new bootstraps > (which automatically upgrade portage right off the bat), an injection of the > compat package would be advisable- unless they downgrade portage, they will > never need the old eclasses. 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. > 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. -- [email protected] mailing list
