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