Patrice Clement wrote:
> Hello everyone,
> 
> I've been busy and quiet since my last email; indeed, I had busy times due to
> school related things to do (mostly exams). You surely know what it means.. :)
> 
> Let's talk about my GSoC project and things I've done since the last time I
> gave you information.
> 
> I wrote many ebuilds, in order to emerge some specific parts of NetBSD. There
> is one eclass, which is used to fetch sources using CVS. This eclass is also
> used to specify where sources are downloaded on the system. End-user can
> specify a personnal path and a special CVS tag to fetch sources.
> 
> As I said on my Trac wiki, you can build-up a NetBSD system using my ebuilds.
> Actually, using ROOT option, I've been able to setup a working NetBSD system,
> chroot inside the ROOT directory and been able to compile some C source code
> with GCC: just a simple "hello world!". But it proves that GNU as and GNU ld
> work with GCC, as well as include headers. So, I think the toolchain fully
> works.
> 2 or 3 ebuilds are missing: /usr/share, /rescue and maybe /usr/games. Not to
> mention an important ebuild: NetBSD kernel!
> 
> Now, my work will focus on bulk build Portage tree, and determine which ebuilds
> work/fail during compilation process. After some tests, I have to install
> Portage packages into a 3rd party directory, something like /usr/pkg (default
> location using pkgsrc) or /usr/local. Why ? I've tried to emerge bash: bash
> depends on ncurses, so I emerged ncurses before bash. ncurses compiled fine
> (yes!) but while installing it, a lot of files conflicted with existing files
> (mainly /usr/lib and /usr/include). My searches, to set up a different prefix
> than the default one used in ebuild.sh (/usr) lead me to an interesting Gentoo
> project: Gentoo Prefix. I'll dig on this to see if I can use it or not. But it
> seems clear to me that I MUST use a different prefix to install packages.
> 
> Any comments/suggestions are welcome, please don't hesitate!
> 
> Thanks for reading and have a nice day.
> 
> Patrice
> 

That's not the best approach, you should make your ebuilds avoid
installing parts of the OS that are installed from portage (ncurses,
bash, ssh, ssl, etc).
Take a look at the 'REMOVE_SUBDIRS' variable and pkg_setup() function of
sys-freebsd/freebsd-lib ebuilds (and eclass) for an example.
Then, when you build into a different ROOT add the proper dependencies
into the netbsd-* ebuilds, so that anything (includes, libraries)
required by NetBSD userland are pulled (installed by portage) before
installing the NetBSD ebuilds.
A (somewhat) easy way to do this would be to disable 'collision-protect'
from portage's FEATURES, to achieve a (not so much)proper portage/Gentoo
chroot, but saving these (reported anyway) collisions so you can remove
these from the netbsd-* ebuilds afterwards.

Have fun! :+)

Javier.