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

[Jason Stubbs]

On Saturday 26 November 2005 02:05, Ned Ludd wrote:
> On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
> > On Saturday 26 November 2005 00:31, Ned Ludd wrote:
> > > * 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)

Heh.. that was my suggestion. ;)

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

Sounds good for pretty much all aspects of split debug (other than the 
capability itself).

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

FEATURES="splitdebug|stripdebug" and do nothing if neither is set?

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

Code cleanups are always good. :)

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

Again, if it can be done cleanly code-wise no issues with resolving the USE 
flags out.

> One big advantage for me here is that virtuals would be resolved.

Resolving virtuals can't be done. Virtuals are meant to be binary compatible 
with each other which means that they can be replaced by each other 
interchangeably. However, once portage starts using info from vdb (soon) and 
starts doing proper sanity checking (not so soon) one would need to re-emerge 
all reverse dependencies in order to switch installed virtual provider.

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

Yes, but an extension to emaint will be needed to create the files for 
existing installed packages. I'm not sure that Brian's plugin architecture is 
ready for .54 so it would need to be another hardcoded check/fix into emaint 
itself. Not sure I really like that idea but I'm not going to fight if the 
majority think that it should go into .54... What do the majority think?

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

This is definitely not something that could be done in any of 2.x unless it's 
done as an external tool (which would not be so hard as order doesn't matter 
with binary packages). I'm not sure that I like the idea of selectively 
ignoring *DEPEND in 3.x anyway - by that stage sanity checking should be 100% 
but selective *DEPENDs will either poke huge holes through it or make a huge 
mess. Either way, it's not a tomorrow thing so discussion should probably 
wait until it's more viable.

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