(accidentially sent this directly to Daniel, re-sending..) 24. feb. 2012 09.29 skrev Daniel Gollub <gollub@b1-systems.de>:
Hi Crasten, Hi Uwe, Hi, some quick comments while I parse through your other mails on OBS dependencies.
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 changes. 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:
https://github.com/stskeeps/obs-build/commit/0687c00013901bdba893f2b69289919...
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: https://github.com/stskeeps/open-build-service/commit/7fced08b7c2eecf93e82b5...
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: https://github.com/stskeeps/osc/commit/f0ba509e308d630345d0e064d7aa3856c5ae5...
If "Required(host):" would work for you - we could go with that in the osc as well. The less patches to add the better, much easier to deploy then.
BR Carsten Munk -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org