On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote:
> 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. ;)
Yeah it seems doable for .53 but if you want to wait till .54 or
a .53-rXX thats fine. I'd prefer to see it in .53 unless
that's going out the door today.
> > > > * 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 ?
>
> 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?
If feature based it seems logical to me to have it as either
splitdebug || nosplitdebug
I know some people hate no* functions or rather they hate no* USE
flags. But it would seem fitting if we decided to make it a default vs
sticking in splitdebug in all profiles.
The feeling I get in general is that some devs want it by default to
make helping users who don't really know how to debug give us the info
we need without much hassles.
stripdebug I'm not sure what you envision with that name.
> > > > * 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.
Should only be a few lines of code. (I hope)
Something like hand off the env varable from dyn_compile() in ebuild.sh
to python and python passes it back to ebuild.sh in the next phase for
dyn_install() which gets recorded flattened
If it's not doable then I'll just go for a simple cosmetic patch to
remove newlines and extra spaces.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
[email protected] mailing list
