Hi Carsten, 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 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@b1-systems.de 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@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org