Re: [gentoo-portage-dev] .53, .54 and beyond...

[Jason Stubbs]

On Monday 28 November 2005 03:49, Marius Mauch wrote:
> 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.

The ldconfig bug and the exec cleanup are the only urgent ones among them. The 
exec cleanup could be postponed and the existing code twiddled in a couple of 
places to fix the logging bug. However, the biggest issue that users are 
complaining about at present is the caching. The biggest issue for devs is 
security. Hence my original list:

* cache rewrite
* exec cleanup
* ldconfig fix
* sha1 enabling

The cache rewrite has existing for many months and has gone through a fair bit 
of testing so I personally don't have any issues with it going into stable. 
As I said, the exec cleanup could be postponed and the existing code twiddled 
only where necessary...

This is more what I was hoping for 2.0.54. It should really follow hot on the 
heals of 2.0.53 and be in stable hopefully by the end of the year. If 
everybody's happy with that, the remainder is:

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

When I said "shortterm goals" in the original email, I was actually referring 
to after 2.0.54. ;)

--
Jason Stubbs
-- 
gentoo-portage-dev@g.o mailing list