Jason Stubbs wrote:
On Sunday 27 November 2005 00:09, Marius Mauch wrote:

Jason Stubbs wrote:
Well, the vote was more for the SHA1 change actually as that's the one
triggering the size increase. The pycrypto stuff itself doesn't do
anything really, it would just make the size increase more apparent.

Hmm.. I thought it was for hashes supported by pycrypto being added into Manifest before Manifest2 comes along. If it was with regard to SHA1 then I take back my vote to delay.

Yeah, I guess the mail could be read both ways.

Don't think so given that offhand I don't even know what getlist() does ...

getlist() is defined in emerge and is used to access the system and world sets. It wouldn't be too hard to customize it to handle user sets and modify other code to support them but the "can't combine sets and atoms" rule would get a bit messy.

So gutting of emerge ... nope, tried that two times already, but gave up after hitting too many direct references to system and world.

Oh, btw, two things that are in trunk but weren't listed in your
original mail:
- the rewritten versioning code (including the cvs and mult-suffix
enhancements)
- finally killing of the stupid "masked by -*" message


That makes the current list for .54:

* autouse death
* cache rewrite
* dyn_install cleanup
* einfo logging
* exec cleanup
* flattened vdb *DEPENDs
* hash support via pycrypto
* ldconfig fix
* metascan/auxget
* postsync hooks
* recursive grab*
* RRDEPEND/LDEPEND
* sha1 enabling
* splitdebug
* vdb empty file culling

Are we about there yet? Also, what does this mean for 2.1/2.2?

Well, if that featurelist is .54 then I really don't see a point for making a 2.1 or 2.2 release line. Before your mail starting this thread I assumed that .54 would just contain the ldconfig fix, the hash stuff and maybe a few other minor things, while trunk would become 2.2. But if things like elog, the new cache subsystem, splitdebug or the *DEPEND changes don't qualify for a "minor" version bump, then I can't think of anything that would.

Marius
--
gentoo-portage-dev@gentoo.org mailing list

Reply via email to