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

[Ned Ludd]

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)

solar@simple 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 <solar@g.o>
Gentoo Linux

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