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

[Jason Stubbs]

On Sunday 27 November 2005 00:09, Marius Mauch wrote:
> Jason Stubbs wrote:
> > On Saturday 26 November 2005 11:07, Marius Mauch wrote:
> >>On Sat, 26 Nov 2005 00:01:15 +0900
> >>
> >>Jason Stubbs <jstubbs@g.o> wrote:
> >>>The only other new thing in trunk that I know of is logging but
> >>>there's still a question mark over the ordering of messages... Can
> >>>that be resolved soon? Anything else missing? Any reasons against any
> >>>of the above?
> >>
> >>Resolved how? I'm not really sure I understood the original problem
> >>(other than listdir being underdeterministic in theory).
> >
> > TGL suggested that all the messages go into a single file with some sort
> > of prefix that would then be parsed on the python side. The original
> > order of messages could then be maintained. However, seeing as there
> > needs to be no compatibility with the temporary files it could wait for
> > later anyway.
>
> a) haven't seen a patch for it, so no clue about how complex it is code
> wise and b) I generally dislike any markup/parsing in the temporary
> files. I'd rather get it out as-is now and incorporate any feedback
> later. As you said this "interface" doesn't have to be compatible, also
> I intended to add a general "might change"-note for elog in the release
> notes.

Yep, fair enough.

> >>- the pycrypto hash additions (for .54)
> >
> > This is only useful if the vote goes in favour of adding further hash
> > types to Manfiest, right? If the vote goes that way I've got no issues
> > with it, but if it doesn't it would essentially be dead code.
>
> 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.

> >>- the recursive grab* functions I just posted (for .54)
> >
> > Needs a small amount of work (/etc/portage/package.mask/foo/bar would
> > break it) but I like the general idea.
>
> How would it break?

Ahh, never mind. I mis-parsed the grablines call within grablines.

> >>- integration of set modules, either as emerge targets (requires
> >>serious gutting of emerge) or a first-class atoms (semantically
> >>tricky, no clue about implementation yet)
> >
> > I'm working on this with my refactoring. Defininately a post-.54 thing
> > unless you want to quickly hack it into getlist()?
>
> 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.

> 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?

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