Re: [gentoo-dev] portage-2.1_alpha20050718 out

[Brian Harring]

On Fri, Aug 12, 2005 at 10:14:35AM +0900, Jason Stubbs wrote:
> On Friday 12 August 2005 02:26, Marius Mauch wrote:
> > Hi,
> >
> > For all those drooling over their keyboards after reading this topic,
> > please also read the rest of this mail.
> > So yes, finally a portage-2.1 pre-pre-pre-alpha version is out and in
> > the tree (p.masked). However, it's not the 2.1 that some of you might
> > expect as it doesn't have a new dep resolver, so still no use deps.
> >

Couple of other things...
1) use sandbox 1.2.12.  if you use 1.2.11 (stable), ebuild-daemon will 
   be a bit borked whenever sandbox is enabled. 

2) Cache rewrite, eclass_cache and actual tree cache are now one, and 
   cache classes are repository wide.
   English: remote cache is sane now, but the rewrite in 2.1 *will* 
   lack a faster searchDesc; the short version is that 2.1 lacks the 
   restriction subsystem, as such it's still the old crappy approach

3) fakeroot integration.  Allows you to run the install phase as 
   non-root, enabled via FEATURES="userpriv_fakeroot".  Remaining 
   ebuild phases that are ran as root are prerm, postrm, preinst, 
   postinst, and setup (why again must setup be root? :)

4) confcache.  Stuart came up with a nifty hack that relies 
   on sandbox debug logs to track what autoconf checks for configure 
   calls; uses this information to maintain an autoconf cache, 
   speeding up configures pretty massively.  Doesn't play nice on 
   multifreq procs (sorry cpu-freq users) due to changing md5 of 
   /proc/cpuinfo, and still has a few bugs.  Useful, but a bit raw.

5) parallelized fetching when FEATURES="parallel-fetch" is on.  Kicks
   in whenever pkg list is > 1, requires FEATURES="distlocks" to be 
   enabled.

6) save/restoration of ebuild envs; bug 56408.  So... a few ebuilds 
   may not play nice.  If you find one, note it's a bug *strictly* 
   for an experimental/alpha version of portage, so do the legwork, 
   and notify the maintainer of what needs to be changed so that the 
   ebuild works with stable *and* with upcoming changes.
   Haven't hit many of them, but their are still a few lingering I'm 
   sure.
   Bonus of it, is that you can yank eclasses from the tree once this 
   is deployed (do it now, and the long standing threat of breaking 
   the devs knees will be executed).

7) metadata.xml *basic* integration.  emerge -sv uses it.
   This is *strictly* just a UI parsing of metadata.xml's, dumping
   maintainer, herd, etc.

8) code clean up of non-core portage lib (ongoing), and start of 
   modularization, and start of class docs for new stuff.

~harring