* [PATCH] linux-custom: Control linux-libc-dev deployment manually @ 2019-09-10 18:07 Jan Kiszka 2019-09-16 8:27 ` Henning Schild 0 siblings, 1 reply; 6+ messages in thread From: Jan Kiszka @ 2019-09-10 18:07 UTC (permalink / raw) To: isar-users; +Cc: Henning Schild, Cedric Hombourger From: Jan Kiszka <jan.kiszka@siemens.com> Deploying a version of linux-libc-dev that is different from the one Debian uses easily causes problems. We already ran into those when doing a downgrade, but we can also create deadlocks when doing an update. The latter happens in common cross-build scenarios when pushing a new version for the target arch but not providing one for the builder. Avoid such troubles my making the package deployment opt-in. In most cases, we will not depend on such an update because we will rarely exploit new kernel API in userspace packages. We can revert this behavior once we support building packages for both target and host. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- meta/recipes-kernel/linux/files/build-kernel.sh | 7 ------- meta/recipes-kernel/linux/linux-custom.inc | 7 +++++-- 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh b/meta/recipes-kernel/linux/files/build-kernel.sh index 8b7b23b..7b651af 100644 --- a/meta/recipes-kernel/linux/files/build-kernel.sh +++ b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -127,10 +127,3 @@ rm -f linux-image-${PV}_${PV}-1_*.deb fakeroot dpkg-deb -b "${REPACK_LINUX_HEADERS_DIR}" \ linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb rm -f linux-headers-${PV}_${PV}-1_*.deb - -# linux-libc-dev causes dependency problems if we downgrade -# remove it after the build so the downgraded version does not get deployed -LINUX_LIBC_DEV_V=$( dpkg-query --show --showformat '${Version}' linux-libc-dev ) -if dpkg --compare-versions $LINUX_LIBC_DEV_V gt $PV-1; then - rm -f linux-libc-dev_${PV}*.deb -fi diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc index c045b89..e75eed1 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc +++ b/meta/recipes-kernel/linux/linux-custom.inc @@ -26,6 +26,8 @@ KBUILD_DEPENDS ?= "build-essential:native libssl-dev libelf-dev bc git kmod biso KERNEL_DEBIAN_DEPENDS ?= "initramfs-tools | linux-initramfs-tool, kmod, linux-base (>= 4.3~)" KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1" +KERNEL_LIBC_DEV_DEPLOY ?= "0" + do_install_builddeps() { dpkg_do_mounts E="${@ bb.utils.export_proxies(d)}" @@ -61,7 +63,8 @@ dpkg_runbuild() { export KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}" sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} ${PP}/build-kernel.sh ${PP}/${PPS} ${DISTRO_ARCH} - if [ ! -f ${WORKDIR}/linux-libc-dev_${PV}*.deb ]; then - bbwarn "Kernel downgrade detected, not deploying linux-libc-dev" + + if [ "${KERNEL_LIBC_DEV_DEPLOY}" != "1" ]; then + rm -f ${WORKDIR}/linux-libc-dev_${PV}*.deb fi } -- 2.16.4 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually 2019-09-10 18:07 [PATCH] linux-custom: Control linux-libc-dev deployment manually Jan Kiszka @ 2019-09-16 8:27 ` Henning Schild 2019-09-16 8:32 ` Jan Kiszka 0 siblings, 1 reply; 6+ messages in thread From: Henning Schild @ 2019-09-16 8:27 UTC (permalink / raw) To: Jan Kiszka; +Cc: isar-users, Cedric Hombourger Am Tue, 10 Sep 2019 20:07:11 +0200 schrieb Jan Kiszka <jan.kiszka@siemens.com>: > From: Jan Kiszka <jan.kiszka@siemens.com> > > Deploying a version of linux-libc-dev that is different from the one > Debian uses easily causes problems. We already ran into those when > doing a downgrade, but we can also create deadlocks when doing an > update. The latter happens in common cross-build scenarios when > pushing a new version for the target arch but not providing one for > the builder. > > Avoid such troubles my making the package deployment opt-in. In most > cases, we will not depend on such an update because we will rarely > exploit new kernel API in userspace packages. > > We can revert this behavior once we support building packages for both > target and host. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > meta/recipes-kernel/linux/files/build-kernel.sh | 7 ------- > meta/recipes-kernel/linux/linux-custom.inc | 7 +++++-- > 2 files changed, 5 insertions(+), 9 deletions(-) > > diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh > b/meta/recipes-kernel/linux/files/build-kernel.sh index > 8b7b23b..7b651af 100644 --- > a/meta/recipes-kernel/linux/files/build-kernel.sh +++ > b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -127,10 +127,3 > @@ rm -f linux-image-${PV}_${PV}-1_*.deb fakeroot dpkg-deb -b > "${REPACK_LINUX_HEADERS_DIR}" \ > linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb rm -f > linux-headers-${PV}_${PV}-1_*.deb - > -# linux-libc-dev causes dependency problems if we downgrade > -# remove it after the build so the downgraded version does not get > deployed -LINUX_LIBC_DEV_V=$( dpkg-query --show --showformat > '${Version}' linux-libc-dev ) -if dpkg --compare-versions > $LINUX_LIBC_DEV_V gt $PV-1; then > - rm -f linux-libc-dev_${PV}*.deb > -fi > diff --git a/meta/recipes-kernel/linux/linux-custom.inc > b/meta/recipes-kernel/linux/linux-custom.inc index c045b89..e75eed1 > 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc > +++ b/meta/recipes-kernel/linux/linux-custom.inc > @@ -26,6 +26,8 @@ KBUILD_DEPENDS ?= "build-essential:native > libssl-dev libelf-dev bc git kmod biso KERNEL_DEBIAN_DEPENDS ?= > "initramfs-tools | linux-initramfs-tool, kmod, linux-base (>= 4.3~)" > KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1" > +KERNEL_LIBC_DEV_DEPLOY ?= "0" > + > do_install_builddeps() { > dpkg_do_mounts > E="${@ bb.utils.export_proxies(d)}" > @@ -61,7 +63,8 @@ dpkg_runbuild() { > export > KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}" > sudo -E chroot --userspec=$( id -u ):$( id -g ) > ${BUILDCHROOT_DIR} ${PP}/build-kernel.sh ${PP}/${PPS} ${DISTRO_ARCH} > - if [ ! -f ${WORKDIR}/linux-libc-dev_${PV}*.deb ]; then > - bbwarn "Kernel downgrade detected, not deploying > linux-libc-dev" + > + if [ "${KERNEL_LIBC_DEV_DEPLOY}" != "1" ]; then > + rm -f ${WORKDIR}/linux-libc-dev_${PV}*.deb Maybe keep that warning in an else ... "not deploying since KERNEL_LIBC_DEV_DEPLOY=0" And Claudius always suggest to stay away from such boolean variables and use arrays instead. That is easier to layer with "random" layer prios. Henning > fi > } ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually 2019-09-16 8:27 ` Henning Schild @ 2019-09-16 8:32 ` Jan Kiszka 2019-09-16 8:46 ` Henning Schild 0 siblings, 1 reply; 6+ messages in thread From: Jan Kiszka @ 2019-09-16 8:32 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users, Cedric Hombourger On 16.09.19 10:27, Henning Schild wrote: > Am Tue, 10 Sep 2019 20:07:11 +0200 > schrieb Jan Kiszka <jan.kiszka@siemens.com>: > >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> Deploying a version of linux-libc-dev that is different from the one >> Debian uses easily causes problems. We already ran into those when >> doing a downgrade, but we can also create deadlocks when doing an >> update. The latter happens in common cross-build scenarios when >> pushing a new version for the target arch but not providing one for >> the builder. >> >> Avoid such troubles my making the package deployment opt-in. In most >> cases, we will not depend on such an update because we will rarely >> exploit new kernel API in userspace packages. >> >> We can revert this behavior once we support building packages for both >> target and host. >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> meta/recipes-kernel/linux/files/build-kernel.sh | 7 ------- >> meta/recipes-kernel/linux/linux-custom.inc | 7 +++++-- >> 2 files changed, 5 insertions(+), 9 deletions(-) >> >> diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh >> b/meta/recipes-kernel/linux/files/build-kernel.sh index >> 8b7b23b..7b651af 100644 --- >> a/meta/recipes-kernel/linux/files/build-kernel.sh +++ >> b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -127,10 +127,3 >> @@ rm -f linux-image-${PV}_${PV}-1_*.deb fakeroot dpkg-deb -b >> "${REPACK_LINUX_HEADERS_DIR}" \ >> linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb rm -f >> linux-headers-${PV}_${PV}-1_*.deb - >> -# linux-libc-dev causes dependency problems if we downgrade >> -# remove it after the build so the downgraded version does not get >> deployed -LINUX_LIBC_DEV_V=$( dpkg-query --show --showformat >> '${Version}' linux-libc-dev ) -if dpkg --compare-versions >> $LINUX_LIBC_DEV_V gt $PV-1; then >> - rm -f linux-libc-dev_${PV}*.deb >> -fi >> diff --git a/meta/recipes-kernel/linux/linux-custom.inc >> b/meta/recipes-kernel/linux/linux-custom.inc index c045b89..e75eed1 >> 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc >> +++ b/meta/recipes-kernel/linux/linux-custom.inc >> @@ -26,6 +26,8 @@ KBUILD_DEPENDS ?= "build-essential:native >> libssl-dev libelf-dev bc git kmod biso KERNEL_DEBIAN_DEPENDS ?= >> "initramfs-tools | linux-initramfs-tool, kmod, linux-base (>= 4.3~)" >> KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1" >> +KERNEL_LIBC_DEV_DEPLOY ?= "0" >> + >> do_install_builddeps() { >> dpkg_do_mounts >> E="${@ bb.utils.export_proxies(d)}" >> @@ -61,7 +63,8 @@ dpkg_runbuild() { >> export >> KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}" >> sudo -E chroot --userspec=$( id -u ):$( id -g ) >> ${BUILDCHROOT_DIR} ${PP}/build-kernel.sh ${PP}/${PPS} ${DISTRO_ARCH} >> - if [ ! -f ${WORKDIR}/linux-libc-dev_${PV}*.deb ]; then >> - bbwarn "Kernel downgrade detected, not deploying >> linux-libc-dev" + >> + if [ "${KERNEL_LIBC_DEV_DEPLOY}" != "1" ]; then >> + rm -f ${WORKDIR}/linux-libc-dev_${PV}*.deb > > Maybe keep that warning in an else ... "not deploying since > KERNEL_LIBC_DEV_DEPLOY=0" I don't see the point in this warning. It suggests that you do want to deploy, which is actually not true. > > And Claudius always suggest to stay away from such boolean variables > and use arrays instead. That is easier to layer with "random" layer > prios. Can you refer to an example? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually 2019-09-16 8:32 ` Jan Kiszka @ 2019-09-16 8:46 ` Henning Schild 2019-09-17 7:14 ` Claudius Heine 0 siblings, 1 reply; 6+ messages in thread From: Henning Schild @ 2019-09-16 8:46 UTC (permalink / raw) To: Jan Kiszka; +Cc: isar-users, Cedric Hombourger, Claudius Heine Am Mon, 16 Sep 2019 10:32:19 +0200 schrieb Jan Kiszka <jan.kiszka@siemens.com>: > On 16.09.19 10:27, Henning Schild wrote: > > Am Tue, 10 Sep 2019 20:07:11 +0200 > > schrieb Jan Kiszka <jan.kiszka@siemens.com>: > > > >> From: Jan Kiszka <jan.kiszka@siemens.com> > >> > >> Deploying a version of linux-libc-dev that is different from the > >> one Debian uses easily causes problems. We already ran into those > >> when doing a downgrade, but we can also create deadlocks when > >> doing an update. The latter happens in common cross-build > >> scenarios when pushing a new version for the target arch but not > >> providing one for the builder. > >> > >> Avoid such troubles my making the package deployment opt-in. In > >> most cases, we will not depend on such an update because we will > >> rarely exploit new kernel API in userspace packages. > >> > >> We can revert this behavior once we support building packages for > >> both target and host. > >> > >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > >> --- > >> meta/recipes-kernel/linux/files/build-kernel.sh | 7 ------- > >> meta/recipes-kernel/linux/linux-custom.inc | 7 +++++-- > >> 2 files changed, 5 insertions(+), 9 deletions(-) > >> > >> diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh > >> b/meta/recipes-kernel/linux/files/build-kernel.sh index > >> 8b7b23b..7b651af 100644 --- > >> a/meta/recipes-kernel/linux/files/build-kernel.sh +++ > >> b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -127,10 +127,3 > >> @@ rm -f linux-image-${PV}_${PV}-1_*.deb fakeroot dpkg-deb -b > >> "${REPACK_LINUX_HEADERS_DIR}" \ > >> linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb rm -f > >> linux-headers-${PV}_${PV}-1_*.deb - > >> -# linux-libc-dev causes dependency problems if we downgrade > >> -# remove it after the build so the downgraded version does not get > >> deployed -LINUX_LIBC_DEV_V=$( dpkg-query --show --showformat > >> '${Version}' linux-libc-dev ) -if dpkg --compare-versions > >> $LINUX_LIBC_DEV_V gt $PV-1; then > >> - rm -f linux-libc-dev_${PV}*.deb > >> -fi > >> diff --git a/meta/recipes-kernel/linux/linux-custom.inc > >> b/meta/recipes-kernel/linux/linux-custom.inc index c045b89..e75eed1 > >> 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc > >> +++ b/meta/recipes-kernel/linux/linux-custom.inc > >> @@ -26,6 +26,8 @@ KBUILD_DEPENDS ?= "build-essential:native > >> libssl-dev libelf-dev bc git kmod biso KERNEL_DEBIAN_DEPENDS ?= > >> "initramfs-tools | linux-initramfs-tool, kmod, linux-base (>= > >> 4.3~)" KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1" > >> +KERNEL_LIBC_DEV_DEPLOY ?= "0" > >> + > >> do_install_builddeps() { > >> dpkg_do_mounts > >> E="${@ bb.utils.export_proxies(d)}" > >> @@ -61,7 +63,8 @@ dpkg_runbuild() { > >> export > >> KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}" > >> sudo -E chroot --userspec=$( id -u ):$( id -g ) > >> ${BUILDCHROOT_DIR} ${PP}/build-kernel.sh ${PP}/${PPS} > >> ${DISTRO_ARCH} > >> - if [ ! -f ${WORKDIR}/linux-libc-dev_${PV}*.deb ]; then > >> - bbwarn "Kernel downgrade detected, not deploying > >> linux-libc-dev" + > >> + if [ "${KERNEL_LIBC_DEV_DEPLOY}" != "1" ]; then > >> + rm -f ${WORKDIR}/linux-libc-dev_${PV}*.deb > > > > Maybe keep that warning in an else ... "not deploying since > > KERNEL_LIBC_DEV_DEPLOY=0" > > I don't see the point in this warning. It suggests that you do want > to deploy, which is actually not true. > > > > > And Claudius always suggest to stay away from such boolean variables > > and use arrays instead. That is easier to layer with "random" layer > > prios. > > Can you refer to an example? I could look one up. Do you want a code-example or a quote from Claudius? Just put him on cc, he can probably explain it without going through some ml archives. Henning > Jan > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually 2019-09-16 8:46 ` Henning Schild @ 2019-09-17 7:14 ` Claudius Heine 2019-09-17 7:30 ` Jan Kiszka 0 siblings, 1 reply; 6+ messages in thread From: Claudius Heine @ 2019-09-17 7:14 UTC (permalink / raw) To: Henning Schild, Jan Kiszka; +Cc: isar-users, Cedric Hombourger [-- Attachment #1.1: Type: text/plain, Size: 4681 bytes --] Hi, On 16/09/2019 10.46, Henning Schild wrote: > Am Mon, 16 Sep 2019 10:32:19 +0200 > schrieb Jan Kiszka <jan.kiszka@siemens.com>: > >> On 16.09.19 10:27, Henning Schild wrote: >>> Am Tue, 10 Sep 2019 20:07:11 +0200 >>> schrieb Jan Kiszka <jan.kiszka@siemens.com>: >>> >>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>> >>>> Deploying a version of linux-libc-dev that is different from the >>>> one Debian uses easily causes problems. We already ran into those >>>> when doing a downgrade, but we can also create deadlocks when >>>> doing an update. The latter happens in common cross-build >>>> scenarios when pushing a new version for the target arch but not >>>> providing one for the builder. >>>> >>>> Avoid such troubles my making the package deployment opt-in. In >>>> most cases, we will not depend on such an update because we will >>>> rarely exploit new kernel API in userspace packages. >>>> >>>> We can revert this behavior once we support building packages for >>>> both target and host. >>>> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>> --- >>>> meta/recipes-kernel/linux/files/build-kernel.sh | 7 ------- >>>> meta/recipes-kernel/linux/linux-custom.inc | 7 +++++-- >>>> 2 files changed, 5 insertions(+), 9 deletions(-) >>>> >>>> diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh >>>> b/meta/recipes-kernel/linux/files/build-kernel.sh index >>>> 8b7b23b..7b651af 100644 --- >>>> a/meta/recipes-kernel/linux/files/build-kernel.sh +++ >>>> b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -127,10 +127,3 >>>> @@ rm -f linux-image-${PV}_${PV}-1_*.deb fakeroot dpkg-deb -b >>>> "${REPACK_LINUX_HEADERS_DIR}" \ >>>> linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb rm -f >>>> linux-headers-${PV}_${PV}-1_*.deb - >>>> -# linux-libc-dev causes dependency problems if we downgrade >>>> -# remove it after the build so the downgraded version does not get >>>> deployed -LINUX_LIBC_DEV_V=$( dpkg-query --show --showformat >>>> '${Version}' linux-libc-dev ) -if dpkg --compare-versions >>>> $LINUX_LIBC_DEV_V gt $PV-1; then >>>> - rm -f linux-libc-dev_${PV}*.deb >>>> -fi >>>> diff --git a/meta/recipes-kernel/linux/linux-custom.inc >>>> b/meta/recipes-kernel/linux/linux-custom.inc index c045b89..e75eed1 >>>> 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc >>>> +++ b/meta/recipes-kernel/linux/linux-custom.inc >>>> @@ -26,6 +26,8 @@ KBUILD_DEPENDS ?= "build-essential:native >>>> libssl-dev libelf-dev bc git kmod biso KERNEL_DEBIAN_DEPENDS ?= >>>> "initramfs-tools | linux-initramfs-tool, kmod, linux-base (>= >>>> 4.3~)" KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1" >>>> +KERNEL_LIBC_DEV_DEPLOY ?= "0" >>>> + >>>> do_install_builddeps() { >>>> dpkg_do_mounts >>>> E="${@ bb.utils.export_proxies(d)}" >>>> @@ -61,7 +63,8 @@ dpkg_runbuild() { >>>> export >>>> KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}" >>>> sudo -E chroot --userspec=$( id -u ):$( id -g ) >>>> ${BUILDCHROOT_DIR} ${PP}/build-kernel.sh ${PP}/${PPS} >>>> ${DISTRO_ARCH} >>>> - if [ ! -f ${WORKDIR}/linux-libc-dev_${PV}*.deb ]; then >>>> - bbwarn "Kernel downgrade detected, not deploying >>>> linux-libc-dev" + >>>> + if [ "${KERNEL_LIBC_DEV_DEPLOY}" != "1" ]; then >>>> + rm -f ${WORKDIR}/linux-libc-dev_${PV}*.deb >>> >>> Maybe keep that warning in an else ... "not deploying since >>> KERNEL_LIBC_DEV_DEPLOY=0" >> >> I don't see the point in this warning. It suggests that you do want >> to deploy, which is actually not true. >> >>> >>> And Claudius always suggest to stay away from such boolean variables >>> and use arrays instead. That is easier to layer with "random" layer >>> prios. >> >> Can you refer to an example? > > I could look one up. Do you want a code-example or a quote from > Claudius? Just put him on cc, he can probably explain it without going > through some ml archives. Not sure about the issue with the layer priorities, but my point about preferring a small number of feature array instead of many boolean options are more in terms of usability from programmer and user perspective, that they are easier to document and more in line with what people coming form OE/YP are used to. 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: Control linux-libc-dev deployment manually 2019-09-17 7:14 ` Claudius Heine @ 2019-09-17 7:30 ` Jan Kiszka 0 siblings, 0 replies; 6+ messages in thread From: Jan Kiszka @ 2019-09-17 7:30 UTC (permalink / raw) To: Claudius Heine, Henning Schild; +Cc: isar-users, Cedric Hombourger On 17.09.19 09:14, Claudius Heine wrote: > Hi, > > On 16/09/2019 10.46, Henning Schild wrote: >> Am Mon, 16 Sep 2019 10:32:19 +0200 >> schrieb Jan Kiszka <jan.kiszka@siemens.com>: >> >>> On 16.09.19 10:27, Henning Schild wrote: >>>> Am Tue, 10 Sep 2019 20:07:11 +0200 >>>> schrieb Jan Kiszka <jan.kiszka@siemens.com>: >>>> >>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>> >>>>> Deploying a version of linux-libc-dev that is different from the >>>>> one Debian uses easily causes problems. We already ran into those >>>>> when doing a downgrade, but we can also create deadlocks when >>>>> doing an update. The latter happens in common cross-build >>>>> scenarios when pushing a new version for the target arch but not >>>>> providing one for the builder. >>>>> >>>>> Avoid such troubles my making the package deployment opt-in. In >>>>> most cases, we will not depend on such an update because we will >>>>> rarely exploit new kernel API in userspace packages. >>>>> >>>>> We can revert this behavior once we support building packages for >>>>> both target and host. >>>>> >>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>>> --- >>>>> meta/recipes-kernel/linux/files/build-kernel.sh | 7 ------- >>>>> meta/recipes-kernel/linux/linux-custom.inc | 7 +++++-- >>>>> 2 files changed, 5 insertions(+), 9 deletions(-) >>>>> >>>>> diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh >>>>> b/meta/recipes-kernel/linux/files/build-kernel.sh index >>>>> 8b7b23b..7b651af 100644 --- >>>>> a/meta/recipes-kernel/linux/files/build-kernel.sh +++ >>>>> b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -127,10 +127,3 >>>>> @@ rm -f linux-image-${PV}_${PV}-1_*.deb fakeroot dpkg-deb -b >>>>> "${REPACK_LINUX_HEADERS_DIR}" \ >>>>> linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb rm -f >>>>> linux-headers-${PV}_${PV}-1_*.deb - >>>>> -# linux-libc-dev causes dependency problems if we downgrade >>>>> -# remove it after the build so the downgraded version does not get >>>>> deployed -LINUX_LIBC_DEV_V=$( dpkg-query --show --showformat >>>>> '${Version}' linux-libc-dev ) -if dpkg --compare-versions >>>>> $LINUX_LIBC_DEV_V gt $PV-1; then >>>>> - rm -f linux-libc-dev_${PV}*.deb >>>>> -fi >>>>> diff --git a/meta/recipes-kernel/linux/linux-custom.inc >>>>> b/meta/recipes-kernel/linux/linux-custom.inc index c045b89..e75eed1 >>>>> 100644 --- a/meta/recipes-kernel/linux/linux-custom.inc >>>>> +++ b/meta/recipes-kernel/linux/linux-custom.inc >>>>> @@ -26,6 +26,8 @@ KBUILD_DEPENDS ?= "build-essential:native >>>>> libssl-dev libelf-dev bc git kmod biso KERNEL_DEBIAN_DEPENDS ?= >>>>> "initramfs-tools | linux-initramfs-tool, kmod, linux-base (>= >>>>> 4.3~)" KERNEL_HEADERS_DEBIAN_DEPENDS ?= "libc6, libssl1.1" >>>>> +KERNEL_LIBC_DEV_DEPLOY ?= "0" >>>>> + >>>>> do_install_builddeps() { >>>>> dpkg_do_mounts >>>>> E="${@ bb.utils.export_proxies(d)}" >>>>> @@ -61,7 +63,8 @@ dpkg_runbuild() { >>>>> export >>>>> KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}" >>>>> sudo -E chroot --userspec=$( id -u ):$( id -g ) >>>>> ${BUILDCHROOT_DIR} ${PP}/build-kernel.sh ${PP}/${PPS} >>>>> ${DISTRO_ARCH} >>>>> - if [ ! -f ${WORKDIR}/linux-libc-dev_${PV}*.deb ]; then >>>>> - bbwarn "Kernel downgrade detected, not deploying >>>>> linux-libc-dev" + >>>>> + if [ "${KERNEL_LIBC_DEV_DEPLOY}" != "1" ]; then >>>>> + rm -f ${WORKDIR}/linux-libc-dev_${PV}*.deb >>>> >>>> Maybe keep that warning in an else ... "not deploying since >>>> KERNEL_LIBC_DEV_DEPLOY=0" >>> >>> I don't see the point in this warning. It suggests that you do want >>> to deploy, which is actually not true. >>> >>>> >>>> And Claudius always suggest to stay away from such boolean variables >>>> and use arrays instead. That is easier to layer with "random" layer >>>> prios. >>> >>> Can you refer to an example? >> >> I could look one up. Do you want a code-example or a quote from >> Claudius? Just put him on cc, he can probably explain it without going >> through some ml archives. > > Not sure about the issue with the layer priorities, but my point about > preferring a small number of feature array instead of many boolean > options are more in terms of usability from programmer and user > perspective, that they are easier to document and more in line with what > people coming form OE/YP are used to. So what are the rule for clustering features, probably not only boolean values? We only have one here, and abstracting a single case will generally lead to something that does not address the next one. Otherwise, we wait until the second case shows up and do it properly then, with backward compatibility support, of course. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-09-17 7:30 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-10 18:07 [PATCH] linux-custom: Control linux-libc-dev deployment manually Jan Kiszka 2019-09-16 8:27 ` Henning Schild 2019-09-16 8:32 ` Jan Kiszka 2019-09-16 8:46 ` Henning Schild 2019-09-17 7:14 ` Claudius Heine 2019-09-17 7:30 ` Jan Kiszka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox