On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
> On Saturday 26 November 2005 00:31, Ned Ludd wrote:
> > On Sat, 2005-11-26 at 00:01 +0900, Jason Stubbs wrote:
> > > Hi all,
> > >
> > > I don't think there's really anything else that can be done for 2.0.53 so
> > > am thinking that we should probably push _rc7 + docs out and let the arch
> > > teams mark it stable when they're ready (or stick with 2.0.51.22-r3 if it
> > > pleaseth them).
> >
> > [snip]
> >
> > > There's a few things listed on the new
> > > (still unreleased?) project index and I'm looking to get the dependency
> > > stuff refactored and moved out of emerge.. What are the shortterm goals?
> >
> > For me my short term goals are to see these things happen
> >
> > * pax-utils depends ( .53 )
> > * seeing CDEPEND stop being created for the VDB ( .53 )
>
> Definitely doable.
>
> > * post_sync action hook (.53/.54 )
> > * VDB prevention of single byte NULL entries being created. ( .54 )
>
> Doable for .54.
Yeah and from the sounds of it we may want more than 1 set of postsync
hooks or the addition of a postsync.d/
(dev thread on getting vital info to users)
> > * new prepstrip offering splitdebug ( .53/.54 )
>
> Need to work out exactly what will be offered when on this one, but at the
> earliest it will be .54. Perhaps go with your patch for .54 and leave
> Olivier's fancy bits for later?
I can only assure you the code I wrote will function properly.
So that's the only thing I'm trying/willing to push myself.
As long as he has those [ -x checks ] his code should be harmless,
but I don't see the advantage in it over building with -g3.
> There are a few other questions too... Should
> the default be to generate external debug info?
I think the security team would say yes they want it by default and
would be willing (taviso) to write a proper debug-HOWTO.xml for gentoo.
I think ferringb would say make it FEATURES=splitdebug if
it's going in midstream.
It does add some size which would make peoples $ROOT's a little bit
bigger. But from mine and other peoples testing it's pretty damn
minimal. I think Halcy0n @ gentoo said after doing an -e world he ended
up with only 18M of split debug info
I'm also fond of split packaging of debug info also (but I'm not going
to push for that till I find a more elegant way)
[EMAIL PROTECTED] debug $ qsize pax-utils
app-misc/pax-utils-debug-0.1.4-r0: 3 files, 5 non-files, 16.27 KB
app-misc/pax-utils-0.1.4: 6 files, 6 non-files, 102.485 KB
Perhaps we should get input from gentoo-dev ml ?
> Should generating internal
> debug info still be offered?
When FEATURES=nostrip is enabled we should not split off
any debug info or touch the executable.
> What platforms is it supported on?..
Everywhere ELF is a standard.
> > * misc cleanups of dyn_install (.54 )
>
> Need more info.
This is just something I want todo for my own sanity,
ie break parts of our existing dyn_install() out
into /usr/lib/portage/bin/ scripts.
The current function is about 209 lines of code and I
can see it growing even more.
> > * flattened vdb {P,R,}DEPEND (.54 )
>
> I might be wrong but I can't really see this being done cleanly. At best,
> only
> USE flags could be gotten rid of which would still leave || () constructs.
> This leads me to question of what use it would really be. If it can only do a
> half-arsed job and in a messy way at that I'd personally prefer it to be done
> later on.
It will indeed still leave you with || ( foo bar ) or >=cpv which you
can be parsed just fine. Yeah it would be nice if it could be reduced
more but later on or now I don't see how it can be reduced anymore than
to the requirements that the ebuild requested. One big advantage for me
here is that virtuals would be resolved.
This will probably lead to an overall reduction in size of the VDB.
> > * introduction of RRDEPEND to the VDB ( .54 )
>
> What is this again?
Ok I talked a little bit about this on this list the other day and a few
months ago with you on #-portage.
<man>
RRDEPEND
This entry is automatically created by portage. It contains a
list of reverse dependencies that is achieved by resolving the
DT_NEEDED entries of an ELF executable.
</man>
Justification
Programs such as revdep-rebuild, verify-rdepend would be able to make
immediate use. A little bit of a longer term goal is to see portage gain
the ability to request to only use RRDEPEND entries to be used for
depgraph creation for use with embedded/mimimal systems.
ROOT=/dev/shm/minimal emerge -KO --deps="RRDEPEND" pkgfoo
RRDEPEND will need to exist due to the RDEPEND explosion and lack of a
clear definition when it was first introduced to portage.
The advantage from where I'm sitting is that devs don't really have a
chance to make mistakes with R/DEPEND handling and people who are
attempting to stage $ROOT can get exactly what they are after in the
embedded world.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-portage-dev@gentoo.org mailing list
