List Archive: gentoo-embedded
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
-----BEGIN PGP SIGNED MESSAGE-----
On 7 Nov 2003 10:36, Ned Ludd emitted:
> From the pure amount of fundamental changes that are going to be needed
> in portage I also suggest that somebody from the dev-portage herd join
> the embedded herd or vice versa to help facilitate faster portage
> commits in directory's such as /home/cvsroot/gentoo-src/portage/bin
> which currently seem to take about 30 or more days from when something
> is reported.
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.
The reason I ask is that it occurs to me that some things that we might want
(like, for example, multiple target platforms for the same emerge process,
platform-specific patching, tracking local source tree changes) would provoke
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.
Memes are a hoax. Pass it on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----
email@example.com mailing list