[SoC 2009] News & progress about porting Portage on NetBSD/x86

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[SoC 2009] News & progress about porting Portage on NetBSD/x86

Patrice Clement-2
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

Reply | Threaded
Open this post in threaded view
|

Re: [SoC 2009] News & progress about porting Portage on NetBSD/x86

Javier Villavicencio-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: [SoC 2009] News & progress about porting Portage on NetBSD/x86

Patrice Clement-2
Tuesday 07 Jul 2009 12:26:27 (-0300), Javier Villavicencio wrote :

> 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.
>
Hi Javier,

Thanks for the answer!

I've looked at your ebuilds many times, to seek inspiration writing mines. :)
I'm a bit lost when you say that installing libraries from NetBSD CVS sources
isn't the best approach. Shouldn't we use it instead of the ones in the portage
tree ? I mean.. does the entire system will still work ?
OpenSSL, SSH, etc .. (libraries & headers), on FreeBSD does it still work while
using Portage sources instead of FreeBSD base system sources ?

About REMOVE_SUBDIRS, when src_install() is called, directories listed inside
this variable aren't installed on the system, am I right ?

Thank you.

Have a nice day!

Patrice

Reply | Threaded
Open this post in threaded view
|

Re: [SoC 2009] News & progress about porting Portage on NetBSD/x86

Javier Villavicencio-2
Patrice Clement wrote:
> Tuesday 07 Jul 2009 12:26:27 (-0300), Javier Villavicencio wrote :
> Hi Javier,
>
> Thanks for the answer!
>
> I've looked at your ebuilds many times, to seek inspiration writing mines. :)

They aren't all mine! :+P

> I'm a bit lost when you say that installing libraries from NetBSD CVS sources
> isn't the best approach. Shouldn't we use it instead of the ones in the portage
> tree ? I mean.. does the entire system will still work ?
> OpenSSL, SSH, etc .. (libraries & headers), on FreeBSD does it still work while
> using Portage sources instead of FreeBSD base system sources ?
>

Yep, the entire system still works (unless something really 'outdated'
is being used by the *BSD OS, in that case it's safe to fix adding our
own patches on the *BSD code). Whatever can be installed from portage's
ebuilds should be installed from there (it will also save you a lot of
trouble on dependencies at a later stage).

> About REMOVE_SUBDIRS, when src_install() is called, directories listed inside
> this variable aren't installed on the system, am I right ?
>
> Thank you.
>
> Have a nice day!
>
> Patrice
>

REMOVE_SUBDIRS is done (also) when (freebsd_)src_unpack() is called.
Check what it does from bsdmk.eclass/freebsd.eclass, it is done to avoid
installing/compiling the unnecessary code as well.

Javier.