Re: [PATCH 2/2] ci: Add compat arch support

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 10 Sep 2020 08:54:00 +0200
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 10.09.20 08:51, [ext] Jan Kiszka wrote:
> > On 09.09.20 15:44, Henning Schild wrote:  
> >> On Tue, 8 Sep 2020 10:53:58 +0200
> >> "[ext] Jan Kiszka" <jan.kiszka@siemens.com> wrote:
> >>  
> >>> On 04.09.20 14:47, [ext] Jan Kiszka wrote:  
> >>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>
> >>>> Build hello-isar and libisar for the compat arch if that is
> >>>> enabled. Set ISAR_ENABLE_COMPAT_ARCH for all supported
> >>>> combinations in CI.
> >>>>
> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>> ---
> >>>>  meta-isar/recipes-app/hello-isar/hello-isar.bb | 3 +++
> >>>>  meta-isar/recipes-app/libhello/libhello.bb     | 3 +++
> >>>>  scripts/ci_build.sh                            | 6 ++++++
> >>>>  3 files changed, 12 insertions(+)
> >>>>
> >>>> diff --git a/meta-isar/recipes-app/hello-isar/hello-isar.bb
> >>>> b/meta-isar/recipes-app/hello-isar/hello-isar.bb index
> >>>> 144a433e..8c3ba8b2 100644 ---
> >>>> a/meta-isar/recipes-app/hello-isar/hello-isar.bb +++
> >>>> b/meta-isar/recipes-app/hello-isar/hello-isar.bb @@ -20,4 +20,7
> >>>> @@ SRC_URI = " \
> >>>> file://yet-another-change.txt;apply=yes;striplevel=0" SRCREV =
> >>>> "a18c14cc11ce6b003f3469e89223cffb4016861d" 
> >>>> +# NOTE: This is just to test 32-bit building on 64-bit archs.
> >>>> +PACKAGE_ARCH_compat-arch = "${COMPAT_DISTRO_ARCH}"
> >>>> +
> >>>>  inherit dpkg
> >>>> diff --git a/meta-isar/recipes-app/libhello/libhello.bb
> >>>> b/meta-isar/recipes-app/libhello/libhello.bb index
> >>>> ab271b58..5c44de50 100644 ---
> >>>> a/meta-isar/recipes-app/libhello/libhello.bb +++
> >>>> b/meta-isar/recipes-app/libhello/libhello.bb @@ -13,4 +13,7 @@
> >>>> PV = "0.1-98f2e41" SRC_URI =
> >>>> "git://github.com/ilbers/libhello.git;protocol=https;destsuffix=${P}"
> >>>> SRCREV = "98f2e41e7d05ab8d19b0c5d160b104b725c8fd93" 
> >>>> +# NOTE: This is just to test 32-bit building on 64-bit archs.
> >>>> +PACKAGE_ARCH_compat-arch = "${COMPAT_DISTRO_ARCH}"
> >>>> +
> >>>>  inherit dpkg
> >>>> diff --git a/scripts/ci_build.sh b/scripts/ci_build.sh
> >>>> index d2c707b8..461fd5cc 100755
> >>>> --- a/scripts/ci_build.sh
> >>>> +++ b/scripts/ci_build.sh
> >>>> @@ -139,6 +139,12 @@ if [ ! -d "$BUILD_DIR" ]; then
> >>>>  fi
> >>>>  source isar-init-build-env "$BUILD_DIR"
> >>>>  
> >>>> +cat >>conf/local.conf <<EOF
> >>>> +ISAR_ENABLE_COMPAT_ARCH_amd64 = "1"
> >>>> +ISAR_ENABLE_COMPAT_ARCH_arm64 = "1"
> >>>> +ISAR_ENABLE_COMPAT_ARCH_debian-stretch_amd64 = "0"
> >>>> +EOF
> >>>> +
> >>>>  if [ -n "$CROSS_BUILD" ]; then
> >>>>      sed -i -e 's/ISAR_CROSS_COMPILE ?= "0"/ISAR_CROSS_COMPILE ?=
> >>>> "1"/g' conf/local.conf fi
> >>>>     
> >>>
> >>> This triggers a problem:
> >>>
> >>> In a multiconfig setup like our CI, building the 32-bit package
> >>> from both the native 32-bit arch as well as the 64-bit arch now
> >>> races. If the 64-bit arch tries to install its self-built compat
> >>> package, that may just be under re-deployment by the 32-bit arch,
> >>> and the build fails.
> >>>
> >>> Options:
> >>>  - somehow express that both archs provide the same package
> >>> (though that may defeat the purpose of testing the compat build)  
> >>
> >> The purpose is that people want to use compat because they have
> >> just one image.  
> > 
> > Well, one could imagine building a legacy application for both an
> > old ARMv7 device as well as for a new ARMv8 design. All that in one
> > build run (mc:...). Then the user would have to express that
> > my_beloved_legacy_app is actually a dependency that only needs to be
> > built once, and it would not matter if that is done by the armhf
> > buildchroot or via compat by the arm64 one.
> >   
> 
> I think I know the answer for our testing scenario: call the the
> compat-variant of hello-isar "hello-isar-compat" and request that
> package in the 64-bit image. Then both build paths are stressed, and
> everyone gets what is desired.

If you manage to just rename it on the bitbake side ... maybe. Think
about a compat rebuild of a lib where you want to keep using debian
packages using that shared lib and not mess with all deps. You would
also create conflicting packages if you rename in debian.

Henning

> Let me try that later...
> 
> Jan
> 
> >>  
> >>>  - split isar-apt per arch, not just per distro  
> >>
> >> But would the compat not need to include both now, and the mc enemy
> >> would still mess with one of them?  
> > 
> > We would have isar-apt/apt/debian-buster-armhf, debian-buster-arm64
> > etc., but all of them able to carry packages for any arch.
> >   
> >>
> >> - better/more locking around isar-apt readers and writers
> >>  
> > 
> > Nope, that would only paper over the fact that a package is built
> > twice and the one to be used would be chosen by chance. Bad for
> > reliable testing.
> > 
> > Jan
> >   
> >>> Suggestions?  
> >>
> >> Well one thing ... but i do not want to repeat myself ... 
> >>
> >> Henning
> >>  
> >>> Jan
> >>>  
> >>  
> >   
>