* [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