Multiconfig woes

Multiconfig woes

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 1077 bytes --]

Hi,

I'm trying to model building different images for different machines -
but for the same architecture. That promises the reuse of common
packages when everything is modeled properly (the kernel, e.g., will be
configured to enable that). But it also exposes some ugliness.

These are my targets so far:

multiconfig:machine1-distro:image
multiconfig:machine2-distro:image

Both machines will share DISTRO_ARCH but will have different MACHINE
variables, obviously. The image recipe will be widely identical, except
for some machine-specific packages, selected by "package-${MACHINE}". So
far so good.

But now we have the same image target in the same distro-arch work
folder, and that clashes. To resolve that, I also need change PN in the
image recipe to "image-${MACHINE}", and that results in the following
targets:

multiconfig:machine1-distro:image-machine1
multiconfig:machine2-distro:image-machine1

Kind of ugly, having the machine ID twice in this target specification.
Is there any better way to model such a scenario?

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Multiconfig woes

[Henning Schild]

Am Sun, 1 Jul 2018 20:47:38 +0200
schrieb Jan Kiszka <jan.kiszka@web.de>:

> Hi,
> 
> I'm trying to model building different images for different machines -
> but for the same architecture. That promises the reuse of common
> packages when everything is modeled properly (the kernel, e.g., will
> be configured to enable that). But it also exposes some ugliness.
> 
> These are my targets so far:
> 
> multiconfig:machine1-distro:image
> multiconfig:machine2-distro:image
> 
> Both machines will share DISTRO_ARCH but will have different MACHINE
> variables, obviously. The image recipe will be widely identical,
> except for some machine-specific packages, selected by
> "package-${MACHINE}". So far so good.
> 
> But now we have the same image target in the same distro-arch work
> folder, and that clashes. To resolve that, I also need change PN in
> the image recipe to "image-${MACHINE}", and that results in the
> following targets:
> 
> multiconfig:machine1-distro:image-machine1
> multiconfig:machine2-distro:image-machine1
> 
> Kind of ugly, having the machine ID twice in this target
> specification. Is there any better way to model such a scenario?

I would try to model that in another image. Just like isar-image-debug
extends isar-image-base. If you also need to remove stuff you might
need one common include for both.

Henning

> Thanks,
> Jan
> 

Re: Multiconfig woes

[Jan Kiszka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2018-07-02 10:10, Henning Schild wrote:
> Am Sun, 1 Jul 2018 20:47:38 +0200 schrieb Jan Kiszka
> <jan.kiszka@web.de>:
> 
>> Hi,
>> 
>> I'm trying to model building different images for different
>> machines - but for the same architecture. That promises the reuse
>> of common packages when everything is modeled properly (the
>> kernel, e.g., will be configured to enable that). But it also
>> exposes some ugliness.
>> 
>> These are my targets so far:
>> 
>> multiconfig:machine1-distro:image 
>> multiconfig:machine2-distro:image
>> 
>> Both machines will share DISTRO_ARCH but will have different
>> MACHINE variables, obviously. The image recipe will be widely
>> identical, except for some machine-specific packages, selected
>> by "package-${MACHINE}". So far so good.
>> 
>> But now we have the same image target in the same distro-arch
>> work folder, and that clashes. To resolve that, I also need
>> change PN in the image recipe to "image-${MACHINE}", and that
>> results in the following targets:
>> 
>> multiconfig:machine1-distro:image-machine1 
>> multiconfig:machine2-distro:image-machine1
>> 
>> Kind of ugly, having the machine ID twice in this target 
>> specification. Is there any better way to model such a scenario?
> 
> I would try to model that in another image. Just like
> isar-image-debug extends isar-image-base. If you also need to
> remove stuff you might need one common include for both.

That is exactly what I wrote above: isar-image-machine1,
isar-image-machine2. But, combined with the config specification, you
then encode the machine twice.

Jan
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTKX4wA9fvIVGYBbICK1KxveuXnFAUCWznfFAAKCRCK1KxveuXn
FGk8AJ4hBGjuG0M1eJDS/MhLUyFrGPGelQCfWPkkbnD2PuFeFsWjDtr/1mUdNWI=
=d1Hc
-----END PGP SIGNATURE-----

Re: Multiconfig woes

[Henning Schild]

Am Mon, 2 Jul 2018 10:15:19 +0200
schrieb Jan Kiszka <jan.kiszka@web.de>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2018-07-02 10:10, Henning Schild wrote:
> > Am Sun, 1 Jul 2018 20:47:38 +0200 schrieb Jan Kiszka
> > <jan.kiszka@web.de>:
> >   
> >> Hi,
> >> 
> >> I'm trying to model building different images for different
> >> machines - but for the same architecture. That promises the reuse
> >> of common packages when everything is modeled properly (the
> >> kernel, e.g., will be configured to enable that). But it also
> >> exposes some ugliness.
> >> 
> >> These are my targets so far:
> >> 
> >> multiconfig:machine1-distro:image 
> >> multiconfig:machine2-distro:image
> >> 
> >> Both machines will share DISTRO_ARCH but will have different
> >> MACHINE variables, obviously. The image recipe will be widely
> >> identical, except for some machine-specific packages, selected
> >> by "package-${MACHINE}". So far so good.
> >> 
> >> But now we have the same image target in the same distro-arch
> >> work folder, and that clashes. To resolve that, I also need
> >> change PN in the image recipe to "image-${MACHINE}", and that
> >> results in the following targets:
> >> 
> >> multiconfig:machine1-distro:image-machine1 
> >> multiconfig:machine2-distro:image-machine1
> >> 
> >> Kind of ugly, having the machine ID twice in this target 
> >> specification. Is there any better way to model such a scenario?  
> > 
> > I would try to model that in another image. Just like
> > isar-image-debug extends isar-image-base. If you also need to
> > remove stuff you might need one common include for both.  
> 
> That is exactly what I wrote above: isar-image-machine1,
> isar-image-machine2. But, combined with the config specification, you
> then encode the machine twice.

Well you could use any string in the image-name, as long as they
differ. Using the machine again just makes things more obvious. If you
still want different names there is always PROVIDES, or a recipe that
DEPENDS on both images.

Henning

> Jan
> -----BEGIN PGP SIGNATURE-----
> 
> iF0EARECAB0WIQTKX4wA9fvIVGYBbICK1KxveuXnFAUCWznfFAAKCRCK1KxveuXn
> FGk8AJ4hBGjuG0M1eJDS/MhLUyFrGPGelQCfWPkkbnD2PuFeFsWjDtr/1mUdNWI=
> =d1Hc
> -----END PGP SIGNATURE-----