Quoting Jan Kiszka (2019-02-25 09:48:38)
> On 25.02.19 09:44, Claudius Heine wrote:
> > Quoting Jan Kiszka (2019-02-25 09:07:35)
> >> On 23.02.19 11:42, Jan Kiszka wrote:

[..]

> >>> Missed this until I had to deal with it: This does not allow per-image password
> >>> configuration because there is only one, hard-coded isar-cfg-userpw package that
> >>> all images pull. E.g., how to build a release (root account locked) and a debug
> >>> image (well-known insecure or empty password) at the same time now?
> >>>
> >>> We rather need to change the logic to pass the control variables from the host
> >>> down into the chroot during installation where the transient package can then
> >>> evaluate them. Or model this - as a special case - without a package.
> >>>
> >>> Before the release, we should at least prove if the current recipe interface can
> >>> be maintained with the above requirement, so that we do not break it again right
> >>> after that.
> >>>
> >>
> >> The same conceptual issue applies to isar-cfg-localepurge: LOCALE_GEN and
> >> LOCALE_DEFAULT should be configurable on a per-image basis, not a per-build.
> > 
> > You are right! I haven't considered that.
> > 
> > Normally you would not have a 'debug' image and a 'release' image, but
> > different multi/local configurations for that. Having debug images and
> > release images is a anti-pattern for bb based projects IMO and should
> > not be done in Isar.
> 
> This is not true. In the end, you will always have two images of that kind, 
> often defined by different package sets, set in the respective image recipes.

Then we have to think hard about where the configuration of root file
systems should belong. Because that is what we have to solve generally
and not for just this recipe. Because all of that could be different in
a 'debug' image.

We have sshd, ntpd, network, user, locale, ... and of course the
configuration for every custom package to consider. If those should not
be placed in one or more debian packages, and not be updatable over the
repositories, then we need some good interface in the image class, that
works well with the bitbake layering, execution order and task mechanic,
to solve that. Currently I cannot think of a good way to solve that.

> 
> > 
> > But of course if you now have a '*-debug' and '*-release' multiconfig,
> > you cannot build that in parallel if one package is build with two
> > different variables.
> > 
> > And that exactly hits the mark with the problem I have with the way Isar
> > uses multiconfigs and tries to share packages from different
> > multiconfigs.
> > 
> > IMO if you want to continue doing it that way, you would need to have a
> > 'isar-cfg-localpurge-debug' and a 'isar-cfg-userpw-debug'. And do that
> > for all possible other configurations you want to build in parallel...
> 
> Awkward. We need to stop this weird patterns which require too much boilerplate 
> recipes to achieve very simple things. Let's just make these variables per-image.

Yes, it is very awkward. But that is how we would need to do it to have
multiple different configurations in one tmpdir with the current Isar
design.

regards,
Claudius

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net