| 1 |
On Tue, Aug 23, 2005 at 01:58:46PM -0400, Olivier Crete wrote: |
| 2 |
> I havent looked at your new implementation (does it exist).. but yea |
| 3 |
> what you wrote seems to make sense... except that I keep the source code |
| 4 |
> too.. so it would bloat binary packages.. I think it should be done |
| 5 |
> before the packages are made.. or maybe use separate debug and have |
| 6 |
> separate debug packages like RedHat does. |
| 7 |
|
| 8 |
Your choice of what goes into the binpkg is just that, your choice, |
| 9 |
just the same as your choice of what ultimately hits the livefs. |
| 10 |
|
| 11 |
Bit of a shift in terms of how things are designed; repositories are |
| 12 |
base objects, things like package.* filtering and changing |
| 13 |
(package.use) is implemented as wrappers of the repo. Wrapper base is |
| 14 |
implemented, as is the filtering wrappers; for what's discussed above, |
| 15 |
just need to design an appropriate contents filter. |
| 16 |
|
| 17 |
Re: does it exist, yes (in cvs, and now living in svn), better |
| 18 |
question, is it usable yet, no; core was yanked, rebuilding it. This |
| 19 |
is a sizable chunk of why feature requests are on hold- either more |
| 20 |
crap gets duct taped into portage, or design is corrected so |
| 21 |
features/additions/tweaks/whatever is easier to do. Long term |
| 22 |
maintenance/extensibility vs short term gain is the crux of it. |
| 23 |
|
| 24 |
What you're after can be pulled off, and the specification of what |
| 25 |
type of stripping to do can be left to the user's config for that repo; |
| 26 |
intention is to allow you to strip sources for binpkgs fex, while not |
| 27 |
stripping sources for livefs merge. |
| 28 |
|
| 29 |
Just a question of how you define your config; the restriction/depends |
| 30 |
bit referenced in the other thread relates to this, you define the |
| 31 |
classes needed and define your config to use them, using alt. formats |
| 32 |
should be possible (exception: OE format I don't see any way to |
| 33 |
support of what I know). |
| 34 |
|
| 35 |
So... the sources concern is moot. Hell, via the wrapper approach if you |
| 36 |
wanted you would be able to define your own wrapper that splits a pkg |
| 37 |
into chunks, or have the repo do it. Don't really care what you do, |
| 38 |
just care correcting underlying issues, and having the remaining beast |
| 39 |
flexible so people can do whatever crazy crap they want instead of |
| 40 |
directly hacking portage innards. |
| 41 |
|
| 42 |
Sidenote, wrapper approach is how install_mask/no{man,info,doc} will |
| 43 |
be defined, rather then jamming crap into the core. Define it as |
| 44 |
seperate chunks, and you can arbitrarily arrange it, doing whatever |
| 45 |
the hell you want. |
| 46 |
~harring |
Archives