Mailinglist Archive: opensuse-buildservice (214 mails)

< Previous Next >
Re: [opensuse-buildservice] Cross compilation dependency handling
Hi Carsten,

On 02/27/2012 12:33 PM, Carsten Munk wrote:
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.

First try with AdditionalArch we used just the architecture as label,
it was not bind to the scheduler, it just had the same name.

You have alreade seen the new Sysroot code, here the parameters are a
bit different:

Sysroot: <alias> <project> <repo> <arch> <sysroot>

You have to define an alias or label, then the project and repo with
architecture from where the packages should come from, and last the
sysroot where all the things should be installed in.

The packages will have an additional Tag 'sysroot' in the jobfile with
the alias/label of the sysroot have to be installed.


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 scheduler.

Not considered yet, but that should be possible. We are using now
labels too :)


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 substitutions?




Regards,
Christian

--
Christian Schneemann
Linux Consultant & Developer
Mail: schneemann@xxxxxxxxxxxxx

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups