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
pgpQ3cWismCyJ.pgp
Description: PGP signature
