Mailinglist Archive: opensuse-buildservice (214 mails)

< Previous Next >
Re: [opensuse-buildservice] Cross compilation dependency handling
  • From: Carsten Munk <carsten.munk@xxxxxxxxx>
  • Date: Mon, 27 Feb 2012 12:33:24 +0100
  • Message-id: <>
23. feb. 2012 19.21 skrev Daniel Gollub <gollub@xxxxxxxxxxxxx>:
Hi Carsten, Hi Adrian,
On Thursday, February 16, 2012 11:01:15 AM Adrian Schröter wrote:
Am Donnerstag, 16. Februar 2012, 10:43:01 schrieb Carsten Munk:
Daniel Gollub suggested that we work with N amount of 'sysroots' and N
rpm databases and I tend to agree. Right now in SB2 I distinguish
between host (/) and target /target, but it might be more flexible to
do with N targets instead.
Scheduler and Worker modification by Christian:

 * Add new parameter to prjconf for additional architectures

New parameter 'AdditionalArch' added to projectconfiguration (prjconf). This
parameter identifies additional architectures with its sysroot that
should be downloaded during build preparation.

AdditionalArch: <arch> <sysroot>

I've started to look a bit into your code and I have some questions
regarding the intended semantics (because it's probably better to
specify these in order to drive proper implementation). Please correct
me if I have my understanding wrong.

AdditionalArch: <scheduler> <sysroot> (now called Sysroot in the code
it seems) which in effect will put install packages from <scheduler>
into <sysroot> - I like this approach, quite clean way to do it.

Preinstall: and VMinstall: will always go into hostarch (which makes
sense) in order to have a bootable environment

What scope will BuildRequires: dependencies from the package be
resolved with? Will it look within the <scheduler> that it is being
built within?

Will BuildRequires: be dep resolved on all architectures or just one?

Have you considered how to deal with x86_64 cross compiling to x86_64
target as well? (or i586->i586) - that would be a typical use case for
'daily development' kind of things, demo embedded system in a X86 VM
for example. That's why I was thinking of labels instead for

Won't you be having an inconsistent RPM database in the target, as in,
'gcc' package name is not represented in package names when doing

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

< Previous Next >