[gentoo-dev] stripping implementation in portage

[gentoo-dev] stripping implementation in portage

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

Hola all.

Short version, the nostrip feature is a bit funky as an option.  What 
I'm after is effectively building all packages *with* debugging 
information as default, and leaving it up to the repository you're 
merging the package to, to decide on stripping or not.

IOW, if you prefer stripped binaries on your livefs, the stripping occurs 
while merging to the livefs- this leaves you the option 
of having binpkgs that *do* carry non-stripped binaries/libs.  
Situation can be reversed also, for the embedded crowd.

Downside, for people who flat out want stripping across the board, 
it's a bit more flipping it on, although that's addressed via inherit 
support within the underlying config (just take my word on that one :)
Also involves a bit more logic, but that's just implementation voodoo.

So... thoughts?  I'd be particularly curious about any package where 
this wouldn't be viable.

Aside from that, cc'ing both lists, would prefer the discussion on dev 
since the implementation can go either way; preference of if that 
flexibility is desired or not is a user thing, so we discuss it in 
their ml.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stripping implementation in portage

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Tuesday 23 August 2005 07:38, Brian Harring wrote:
> Hola all.
>
> Short version, the nostrip feature is a bit funky as an option.  What
> I'm after is effectively building all packages *with* debugging
> information as default, and leaving it up to the repository you're
> merging the package to, to decide on stripping or not.

Makes sense.

> So... thoughts?  I'd be particularly curious about any package where
> this wouldn't be viable.

I believe xorg-x11 is one such package. But then, this might just be a 
reason for a pkg_strip().

-- 
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stripping implementation in portage

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Stubbs wrote:
| On Tuesday 23 August 2005 07:38, Brian Harring wrote:
|>So... thoughts?  I'd be particularly curious about any package where
|>this wouldn't be viable.
|
|
| I believe xorg-x11 is one such package. But then, this might just be a
| reason for a pkg_strip().

xorg respects FEATURES=nostrip, although it has a custom implementation.

In the modular X, stripping the modules seems to work fine, so we can
get rid of that custom strip.

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDCl5zXVaO67S1rtsRAsAEAKCenAMncB0Hxah0NuQQSP9jujg4nwCeM/C0
zQS/ubpM2M3leUDQ/C/8fWw=
=pfEZ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] stripping implementation in portage

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

On Tuesday 23 August 2005 00:38, Brian Harring wrote:
> Hola all.
>
> Short version, the nostrip feature is a bit funky as an option.  What
> I'm after is effectively building all packages *with* debugging
> information as default, and leaving it up to the repository you're
> merging the package to, to decide on stripping or not.
>
> IOW, if you prefer stripped binaries on your livefs, the stripping
> occurs while merging to the livefs- this leaves you the option
> of having binpkgs that *do* carry non-stripped binaries/libs.
> Situation can be reversed also, for the embedded crowd.
>
> Downside, for people who flat out want stripping across the board,
> it's a bit more flipping it on, although that's addressed via inherit
> support within the underlying config (just take my word on that one :)
> Also involves a bit more logic, but that's just implementation voodoo.
>
> So... thoughts?  I'd be particularly curious about any package where
> this wouldn't be viable.
>
> Aside from that, cc'ing both lists, would prefer the discussion on dev
> since the implementation can go either way; preference of if that
> flexibility is desired or not is a user thing, so we discuss it in
> their ml.

As an aside to this. Does anyone know how debug information can be changed 
to have a different basedir. My idea was to create a "custom" strip 
wrapper that would create external debugging files (like now possible 
with gdb/binutils) and point them to a location 
in /usr/src/packagenameplusversion. For that it would be necessary to in 
some way hack the source location in the debug information.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stripping implementation in portage

[Olivier Crete]

On Tue, 2005-23-08 at 11:16 +0200, Paul de Vrieze wrote:
> As an aside to this. Does anyone know how debug information can be changed 
> to have a different basedir. My idea was to create a "custom" strip 
> wrapper that would create external debugging files (like now possible 
> with gdb/binutils) and point them to a location 
> in /usr/src/packagenameplusversion. For that it would be necessary to in 
> some way hack the source location in the debug information.

There is already a patch [1] in bugzilla that does that.. And in bonus
to keeping the debug files (currently in <libpath>/.debug/libname.so.dbg
but that can be changed) . It can also keep the source files
in /usr/src/debug so they can loaded by gdb (pretty useful when
debugging into libraries). 

It creates 3 new features, keepdebug, keepdebugbin and keepsources

keepdebug will keep the debug symbols for libs
keepdebugbin will keep then for non-lib binaries
and keepsources will keep the related sources..

[1] http://bugs.gentoo.org/show_bug.cgi?id=45150

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] stripping implementation in portage

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

First, sidenote (mild ot to this thread also), pardon the dupe posts, 
thick fingered typing dumping an old message :)

On Tue, Aug 23, 2005 at 01:34:33PM -0400, Olivier Crete wrote:
> On Tue, 2005-23-08 at 11:16 +0200, Paul de Vrieze wrote:
> > As an aside to this. Does anyone know how debug information can be changed 
> > to have a different basedir. My idea was to create a "custom" strip 
> > wrapper that would create external debugging files (like now possible 
> > with gdb/binutils) and point them to a location 
> > in /usr/src/packagenameplusversion. For that it would be necessary to in 
> > some way hack the source location in the debug information.
> 
> There is already a patch [1] in bugzilla that does that.. And in bonus
> to keeping the debug files (currently in <libpath>/.debug/libname.so.dbg
> but that can be changed) . It can also keep the source files
> in /usr/src/debug so they can loaded by gdb (pretty useful when
> debugging into libraries). 
> 
> It creates 3 new features, keepdebug, keepdebugbin and keepsources
Would rather implement those as filters as described above; short 
version is that features is chunked up in the rewrite, so it's options 
on the component you're configuring moreso.  That said, still will map 
from old make.* to new format (on the fly, no forced config upgrades), 
but I'd rather see it implemented as I've proposed.

Reasoning is that if you build with debugging crap on, you've got 
maximal flexibility in your choice of what your binpkgs/vdb winds up 
with.

Thoughts/yay/nays?
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] stripping implementation in portage

[Olivier Crete]

On Tue, 2005-23-08 at 12:40 -0500, Brian Harring wrote:
> First, sidenote (mild ot to this thread also), pardon the dupe posts, 
> thick fingered typing dumping an old message :)
> 
> On Tue, Aug 23, 2005 at 01:34:33PM -0400, Olivier Crete wrote:
> > On Tue, 2005-23-08 at 11:16 +0200, Paul de Vrieze wrote:
> > > As an aside to this. Does anyone know how debug information can be changed 
> > > to have a different basedir. My idea was to create a "custom" strip 
> > > wrapper that would create external debugging files (like now possible 
> > > with gdb/binutils) and point them to a location 
> > > in /usr/src/packagenameplusversion. For that it would be necessary to in 
> > > some way hack the source location in the debug information.
> > 
> > There is already a patch [1] in bugzilla that does that.. And in bonus
> > to keeping the debug files (currently in <libpath>/.debug/libname.so.dbg
> > but that can be changed) . It can also keep the source files
> > in /usr/src/debug so they can loaded by gdb (pretty useful when
> > debugging into libraries). 
> > 
> > It creates 3 new features, keepdebug, keepdebugbin and keepsources
> Would rather implement those as filters as described above; short 
> version is that features is chunked up in the rewrite, so it's options 
> on the component you're configuring moreso.  That said, still will map 
> from old make.* to new format (on the fly, no forced config upgrades), 
> but I'd rather see it implemented as I've proposed.
> 
> Reasoning is that if you build with debugging crap on, you've got 
> maximal flexibility in your choice of what your binpkgs/vdb winds up 
> with.
> 
> Thoughts/yay/nays?

I havent looked at your new implementation (does it exist).. but yea
what you wrote seems to make sense... except that I keep the source code
too.. so it would bloat binary packages.. I think it should be done
before the packages are made.. or maybe use separate debug and have
separate debug packages like RedHat does.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] stripping implementation in portage

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

On Tue, Aug 23, 2005 at 01:58:46PM -0400, Olivier Crete wrote:
> I havent looked at your new implementation (does it exist).. but yea
> what you wrote seems to make sense... except that I keep the source code
> too.. so it would bloat binary packages.. I think it should be done
> before the packages are made.. or maybe use separate debug and have
> separate debug packages like RedHat does.

Your choice of what goes into the binpkg is just that, your choice, 
just the same as your choice of what ultimately hits the livefs.

Bit of a shift in terms of how things are designed; repositories are 
base objects, things like package.* filtering and changing 
(package.use) is implemented as wrappers of the repo.  Wrapper base is 
implemented, as is the filtering wrappers; for what's discussed above, 
just need to design an appropriate contents filter.

Re: does it exist, yes (in cvs, and now living in svn), better 
question, is it usable yet, no; core was yanked, rebuilding it.  This 
is a sizable chunk of why feature requests are on hold- either more 
crap gets duct taped into portage, or design is corrected so 
features/additions/tweaks/whatever is easier to do.  Long term 
maintenance/extensibility vs short term gain is the crux of it.

What you're after can be pulled off, and the specification of what 
type of stripping to do can be left to the user's config for that repo; 
intention is to allow you to strip sources for binpkgs fex, while not 
stripping sources for livefs merge.  

Just a question of how you define your config; the restriction/depends 
bit referenced in the other thread relates to this, you define the 
classes needed and define your config to use them, using alt. formats 
should be possible (exception: OE format I don't see any way to 
support of what I know).

So... the sources concern is moot.  Hell, via the wrapper approach if you 
wanted you would be able to define your own wrapper that splits a pkg 
into chunks, or have the repo do it.  Don't really care what you do, 
just care correcting underlying issues, and having the remaining beast 
flexible so people can do whatever crazy crap they want instead of 
directly hacking portage innards.

Sidenote, wrapper approach is how install_mask/no{man,info,doc} will 
be defined, rather then jamming crap into the core.  Define it as 
seperate chunks, and you can arbitrarily arrange it, doing whatever 
the hell you want.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]