Re: [gentoo-portage-dev] Status of SVN trunk?

[Brian Harring]

First... stating thank you.  This is an ongoing pain in the ass, 
trying to track what everyone has stuck into stable and ensure it's in 
ebd codebase is mildly maddening on a given day.

On Fri, Oct 14, 2005 at 03:01:30PM +0200, Thomas de Grenier de Latour wrote:
> On Thu, 13 Oct 2005 13:21:21 -0500
> Brian Harring <ferringb@g.o> wrote:
>
> > Any updates to 2.1, I'd be curious about since it's bash core is
> > the basis of 3.x
>
> The savior's bash code seems sane compared to the trunk's one.

Trunk being a frozen snapshot of the codebase... kept working on it. 
:)

> Now, compared to 2.0 (and just reading changelog), i see:
>  - some patches missing in both branches: some are new stuffs
> i'm sure you're already aware of (EBUILD_DEATH_HOOK, EAPI support,
> etc.), other are fixes (lchown/lchgrp for instance, but i also see
> something about .tar unpacking in changelog which seems to apply,
> etc.).

Just added EBUILD_DEATH_HOOK and EAPI
assert fixes for unpack are in also (.tar bit)

the lchown/lchgrp changes I'm not pushing forward.  That code I'm 
going to yank out of the bash side, and shove it into python, since 
contents scans will be needed, and should be more efficient.


> I'm okay to try to make some more detailed report with patches, but
> i would first like to know whether trunk is going anywhere. I mean,
> it's obvious that atm noone uses it since it's not even
> syntacticaly correct. That, plus some bugs closed as dups of #102126
> without beeing fixed, makes me wonder... Oh, and also this recent
> email from Marius on gentoo-dev@:
>
> > On Tue, 11 Oct 2005 17:00:56 +0000
> > Alec Joseph Warner <warnera6@×××××××.edu> wrote:
> >
> > > FYI elog is implemented in CVS ( 2.1 ).  When it will be
> > > released is anyone's guess.
> >
> > 2.1? probably never, but elog will almost certainly be backported
> > to the 2.0 branch.
> >
> > Marius
>
> Anyway, don't take me wrong, i'm not trying to flame anyone about
> how portage development is done, or whatever.  If the new route is
> to backport some of the long awaited features to 2.0 until 3.x is
> ready, it's fine for me.

Surprising thing, people are using it- that said, I'm not (nor have I 
been for a few months).  Was using it over stable due to it having 
stuff I wanted, but due to reasons listed below, reverted to a hacked 
up stable...

Meanwhile, spose I'll be the one to do the deed since nobody else is 
speaking up, but yah, 2.1 is dead as a release line.  Pretty much was 
the case from it's initial release, since by that time I'd already 
moved on past it (meaning the ebd related bugs in 2.1 I was no longer 
fixing in 2.1).

Reasons come down to several-
A) lot of underlying structural changes, lot bash side, and shims 
python side to play with bash side
B) said shims (namely the continued existance of of doebuild akin 
code) means we're still going to get idiotic phase bugs like we do 
with stable.  Env handling bash side is bordering on total control, 
but what goes into the env python side is still a god awful mess.
C) backporting chunks of code (cache fex) to 2.0.x line (non-ebd line, 
basically) isn't too hard, and worth the effort.
D) 2.1's base is approaching a year old.  Time for stabling for that 
beast came and went long ago from where I'm sitting, 'specially 
considering the issues in A/B require python side modifications (core 
rewrite), which is what 3.0 is.  We could slide by with the bastardly 
python side ebuild shim, but personally I don't think it's a 
productive route to follow.

So... onto the bugs.

> It's really just that i have a bit of
> free time this days, so i was thinking of updating a few stuffs i
> would like to see included someday (bugs #85786, #83613, #90444,
> #84884, #37498 and #34964 comes to mind), and for that i need to
> know what would be the prefered target.

#85786 (faster config.pusedict)
Stable target from where I'm sitting, since it's a fairly simple 
modification from the standpoint of how much code it touches
Needs testers before it would be considered (get cracking peeps).  Not 
so much a feature as a more efficient version of existing, so... no 
major complaints personally.


#83613 (abspath profile/parent support)
Hesitant on this one; target would have to be stable since the changes 
won't really fit into 3.x (profile being a seperate config obj, can go 
nuts with it).  Either way, hesitant since 
A) changes to profile need to play nice in a backwards compatible way, 
we already have enough issues with .50 profile screwups still. :)
B) if limited to /etc/portage/profile (something of the sort), less of 
an issue.
C) interaction with any code that resets PORTDIR (said code is evil, 
but it exists).

#90444 (faster dblink.getcontents)
Stable target.  Still want the code defensive.
One thing to state, and I'll be going through the rewrite and tagging 
some indirection into utils code till python stable sucks less at 
this, but os.path.normpath is rather slow.

python -m timeit -s 'x="/usr/lib/portage/bin/dar"; from os.path import normpath' 'normpath(x)'
100000 loops, best of 3: 14.1 usec per loop

Note that I'm actually cheating and giving it an advantage by 
importing normpath into local namespace; we wouldn't do that in normal 
code.  It's a difference between 14.6 and 14.1 (pretty minor), but 
continuing...

python -m timeit -s 'x="/usr/lib/portage/bin/dar";from os.path import sep;normpath=lambda x:sep.join(filter(None, x.split(sep)))' \
'normpath(x)'
100000 loops, best of 3: 5.62 usec per loop

If that was straight inlined, it would be 4.94u (this is an instance 
where I would kill for macros).

Either way... bit faster, and still has the protection I want, so 
that's a bit better (imo).

If you're using a faster normpath from above, no issues, since it's 
pretty much deterministic affects wise.


#84884 (use.(local.)?desc integration to emerge UI)
stable target (code won't be needed in 3.0)
Definitely a feature in comparison to others, low priority.


#37498 (single counter for package building/merging, == single log)
Good god you've been at that one for a while from the looks of it :)
sort of a stable target, although that's questionable.  *really* not 
much for the doebuild abuse, but no other alternative.
Basically... this is definitely an enhancement, and while the existing 
behaviour is annoying (my opinion on it), it's not high priority on 
screwing with it... so... jason?  thoughts?

#34964 (binpkg system packages)
Another patch you've been at forever and has suffered the infernal 
bitrot of bugzie...
3.0 target imo.  It's useful, but it's already intended in 3.0, and 
bolting more stuff into 2.0 that has to be duplicated in 3.0 sucks. :)

My 2 cents, in a rather long email...
~harring