Mailinglist Archive: opensuse-buildservice (214 mails)

< Previous Next >
Re: [opensuse-buildservice] RFC: patches for SB2 integration into OBS for better cross compilation,
  • From: Carsten Munk <carsten.munk@xxxxxxxxx>
  • Date: Fri, 24 Feb 2012 10:00:40 +0100
  • Message-id: <>
(accidentially sent this directly to Daniel, re-sending..)

24. feb. 2012 09.29 skrev Daniel Gollub <gollub@xxxxxxxxxxxxx>:
Hi Crasten, Hi Uwe,
Hi, some quick comments while I parse through your other mails on OBS

Uwe, Carsten is addressing similar issue as we do in the obs-build scripts -
you might want to have a look on them so we can collaborate with Carsten.

My goal is that we can have a system that uses similar cross compile
dependency solution as yours (generic is always better), but be able
to differ in code paths on how exactly things get executed - there's
merits to both approaches. Because of SB2 I can do even more
transparent cross compile, including running target binaries, so.

Just to fit this in with what I'm working on: I have a proof of
concept running with SB2 that allows me to have an no-tools-available
target (ie, only glibc, glibc-devel, mostly unmodified rpmrc/macros)
that can build libtool, acl, attr, busybox.. and run ARM binaries
during build too. It's a bit of the same thing you want to do, but
without the need to modify packages/specs or do voodoo rpm config

But I'd want a cleaner solution when it comes to "host" dependencies,
instead of RPM package Provides: magic.

In our case we call multiple times init_buildsystem - to setup the actual
BUILD_ROOT + for each target sysroot we want to setup.
But for the init_buildsystem call for the target sysroots we want to avoid
the chroot calls. In some cases some people might want
to have very limited sysroots which are not suiteable for chroots at all.
Agreed, that seems like a suitable direction and might make the code
significantly cleaner.

For instance all the rpm calls (intalling packages, init-db, quries, ...)
could be done by using the host rpm binary and pointing with "rpm --dbpath"
to target rpm database.
E.g. rpm --dbpath $SYSROOTPATH/var/lib/rpm ... or even use that rpm --root
parameter (I'm still not quite sure if rpm really makes use of chroot on its
own then).

rpm --root=/foo -i foo.rpm will for postscripts chroot in (not the
command, the syscall) and run the script and chroot out again

I think we can possibly do something like enter_target rpm /
enter_target dpkg so we can vary on approaches to running RPM. You'd
want to prefix with --rpmdb / --root for your approach, i'd want to
run sb2 + rpm.

With SB2 are you calling the target rpm binary (and it deps) to do this
initial setup?
Or do you call somehow the native rpm?
In SB2 it's possible to do both. I set up a SB2 target in the target,
which may or may not have /bin/rpm in it. In practice, when the target
rpm binary is executed (or just /bin/rpm attempted to be executed), it
will run the host side 'rpm' with the perception that it is within the
target file system.

(Analog to dpkg)

Maybe additionally to a generic wrapper (which should also support plain
calls and maybe NOOP) we should write for more frequent calls, specific
wrapper - e.g. for rpm / dpkg.
So the rpm / dpkg specific wrapper use the hostarch binaries and point to the
sysroot package database.
Yup, should be trivial to do. needroot/needuser may have to vary
though for the package manager.

Have you tried to just overwrite the BUILD_ROOT in the init_buildsystem to
some "target" direcotry.
No, but it sounds worthwhile to try.

This diff hunk is very useful:

Without that using init_buildsystem to setup a seperated target sysroot fails
to detect the right package-system (deb || rpm).
The target architectures would require the rpm or the deb package as native
dependency to indicating which kind of disto-package-system should be setup:
deb or rpm distro-package-system.

You might want to isolate this diff hunk as seperated patch and and ask to
get this one pulled.
Noted, I'll take out this patch and send it separately - it's very useful.

With regards to your open-build-service change:

Instead of introducing "SB2install" I guess a generic "Required(host):" might
also work for you - right?

Required(host): (which is not yet implemented) would add dependencies for the
host "target" only.
Yes, if we go for your cross dependency approach we wouldn't need SB2install.

Same for your osc change:

If "Required(host):" would work for you - we could go with that in the osc as
The less patches to add the better, much easier to deploy then.

Carsten Munk
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups