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

[Thomas de Grenier de Latour]

On Fri, 14 Oct 2005 16:59:29 -0500
Brian Harring <ferringb@g.o> wrote:

> assert fixes for unpack are in also (.tar bit)

Yup, i've seen the die/assert fixes were in, but there is also
commit #1992, about ${tarvars} placement on the command line.  I
confess i've not understood what the issue was though... :)
Anyway, the 2.0 diff is in attachment, so that you can check
whether it's needed in savior too or not (i see you use "-xf" and
alike in savior, whereas 2.0 uses "xf", so maybe that is actually
enough to make the difference).

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

Oh, if that means there will be a common module framework for all
the contents checking and tweaking features (collision-protect,
INSTALL_MASK, rdepend verification, NEEDED generation,
chowning & chmoding, etc.), then it's just great.

> Surprising thing, people are using it-

Then they are all using hacked version or an old snapshot, and not
"vanilla" trunk from SVN.  Oh well, i shouldn't be surprised after
all, that's what i've done too for months :)

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

Ok, that's good to know, and i understand the reasons.

> #85786 (faster config.pusedict)

Ok, will sync it after i've switched back to 2.0.

> #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.

Backward compat should not be an issue as long as official
profiles continue to use only relative paths for inheriting.
I could add a check to enforce that.

> C) interaction with any code that resets PORTDIR (said code is
> evil, but it exists).

I don't know about that code, will investigate.

> #90444 (faster dblink.getcontents)
> Stable target.  Still want the code defensive.

I personnally still don't really understand what defensive code
protects us against, so i will leave it to you or Jason to take
whatever decision you think is best. 

> #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.

Okay, will sync it. Btw, about the display of flag descriptions by
emerge, i'm opened to any suggestions of better cmdline options
and behavior. For instance, would taking some "verbosity level"
into account ("-v -v", like 2.1's emerge does for some other
metadatas) be better than adding new options?

> #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.

I will probably sync it, at least for my own use, but yes, i agree
that on code side it's a bit adding ugliness to the ugliness just
for fixing a minor annoyance, so i would understand a WONTFIX :)

> #34964 (binpkg system packages)
> Another patch you've been at forever and has suffered the
> infernal bitrot of bugzie...

Same as for the previous one, but more... That one, i can't live
without, so it will be synced anyway. But on the other hand, it's
more code, and is some rather ugly one (i have it currently in my
2.1, and checking of whether a package is system or not is already
not pretty pretty because of local USE flags + conditionnal
provides, and iirc the 2.0 config stuff, it will get worst). So
again, i would understand a wontfix when i will reopen it a third
time :)

> My 2 cents, in a rather long email...

Many thanks for having taken time to go through this bugs list and
for having clarified the branches question. 

-- 
TGL.