On 02/27/2012 12:33 PM, Carsten Munk wrote:
23. feb. 2012 19.21 skrev Daniel Gollub
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
> Daniel Gollub suggested that we work with N
> '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
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
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
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
Linux Consultant & Developer
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(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org