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