On Fri, Nov 07, 2003 at 12:59:25PM -0700, AJ Armstrong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Although I agree that all ebuilds built for the embedded project should be 
> part of the portage tree (probably need some new categories), so that they 
> could be installed using vanilla emerges on platforms with the guts to 
> support it, should we perhaps consider a new emerge (emberge?, emergemb?, 
> crossmerge?), using many of the portage facilities, but designed to support 
> cross-compiling and building a target filesystem, rather than installing on 
> the local box.  This would exist alongside emerge, but have its own config 
> file structure , etc.
> 

Well if you go poke around in buildroot you'll notice they have little
uclibc patches for openssl and openssh... plus a couple other little
tools.
I've made my own uclibc toolchain ebuilds, and believe me they aren't
easy.  Getting gcc to play nice with uclibc is an ugly hack at
best... I'm not sure why gcc doesn't have --libc as a autoconf option.

anyway, my point was... patches for uclibc compat.  It will be
interesting to see how much hackage is needed.  On the one hand uclibc
people see to suggest that everything should 'just work'(tm), but they
provide an awful lot of patches that suggest the contrary.
so making a different tree may be the answer, but keeping it 'in sync'
with gentoo-portage doesn't sound like fun.

> such supstantial changes in portage and things like make.conf that we're 
> unlikely to get them without (1) a long fight (2) giving up some things we 
> want.  Also, multi-platform cross-compiler support is such a significant 
> retrofit that I'm wondering if it wouldn't result in either a nasty 
> bag-on-the-side or a second system effect if we try to re-engineer portage.
> 

maybe we have to put in our suggestions to portage 2.0 redesign and
hope :-(

and as for namings ... I'm partial to submerge ;-) but I felt I was
clever in naming that.
Dave

--
gentoo-embedded@g.o mailing list