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
pgpLZIfXX01Jd.pgp
Description: PGP signature
