On Tue, Sep 28, 2021 at 10:16 AM Zoltan Boszormenyi via
lists.openembedded.org <zboszor=pr...@lists.openembedded.org> wrote:
>
> From: Zoltán Böszörményi <zbos...@gmail.com>
>
> When using dnf to install new kernel versions and installonly_limit
> is reached, dnf automatically removes the oldest kernel version.
What about other package managers ? Is there a similar limit ? And
does the fallback still work the same ?
I can't say that I'm aware of exactly what this dnf limit is, can we
either link to it, or document the value in the commit message ?
And just so I understand, this is on the install (not the removal)
that dnf is removing the oldest kernel (by its versioning checks) when
the limit is hit ?
>
> However, the /boot/bzImage symlink (or whatever image type is used)
> is removed unconditionally.
And this removal, that's on the package uninstall ? or is that also a
dnf install quirk ?
>
> Allow using the alternative symlink machinery so the highest
> kernel version takes precedence and the symlink stays in place.
>
> Signed-off-by: Zoltán Böszörményi <zbos...@gmail.com>
> ---
> meta/classes/kernel.bbclass | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index deccc0e58c..a687e5259d 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -43,9 +43,17 @@ KERNEL_VERSION_PKG_NAME =
> "${@legitimize_package_name(d.getVar('KERNEL_VERSION')
> KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"
>
> python __anonymous () {
> + import re
> pn = d.getVar("PN")
> kpn = d.getVar("KERNEL_PACKAGE_NAME")
>
> + # KERNEL_VERSION cannot be used here as it would cause
> + # "basehash value changed" issues.
> + kver = d.getVar("PV")
> + kverp = re.compile('[\.-]')
> + kvparts = kverp.split(kver)
> + kverstr =
> str(kvparts[0])+str(kvparts[1]).zfill(2)+str(kvparts[2]).zfill(3)
It would be really nice to avoid this logic, since in my years of
suffering, PV cannot be trusted on this front.
Why can't this use KERNEL_VERSION_PACKAGE_NAME ? It is already used in
this anonymous python code, and as the vardepexclude (which may just
be what you need to use KERNEL_VERSION directly).
> +
> # XXX Remove this after bug 11905 is resolved
> # FILES:${KERNEL_PACKAGE_NAME}-dev doesn't expand correctly
> if kpn == pn:
> @@ -117,6 +125,9 @@ python __anonymous () {
> d.setVar('PKG:%s-image-%s' % (kname,typelower),
> '%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
> d.setVar('ALLOW_EMPTY:%s-image-%s' % (kname, typelower), '1')
> d.setVar('pkg_postinst:%s-image-%s' % (kname,typelower), """set +e
> +if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
> + update-alternatives --install ${KERNEL_IMAGEDEST}/%s %s
> %s-${KERNEL_VERSION_NAME} %s
> +else
I know it is just an inline postinst, but this is starting to get
unreadable quickly.
Shouldn't $D come into play here ? i.e. the existing postinst snippet
is taking it into account for doing the install, update alternatives
should also know if it is defined as well. Shouldn't this be in the
else block of the [ -n "$D" ] test ? if it shouldn't, can the entire
else block be indented to show that it is conditional on the variable
you are introducing.
Are there any situations where update-alternatives isn't available ?
kind of like how we test for ln -sf, and do a fallback if it fails. Is
there a similar case for update-alternatives ?
> if [ -n "$D" ]; then
> ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
> else
> @@ -126,14 +137,19 @@ else
> install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION}
> ${KERNEL_IMAGEDEST}/%s
> fi
> fi
> +fi
> set -e
> -""" % (type, type, type, type, type, type, type))
> +""" % (type, type, type, kverstr, type, type, type, type, type, type, type))
> d.setVar('pkg_postrm:%s-image-%s' % (kname,typelower), """set +e
> +if [ "${KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES}" != "0" ]; then
> + update-alternatives --remove %s %s-${KERNEL_VERSION_NAME}
> +else
> if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
> rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
> fi
> +fi
> set -e
> -""" % (type, type, type))
> +""" % (type, type, type, type, type))
>
>
> image = d.getVar('INITRAMFS_IMAGE')
> @@ -214,6 +230,7 @@ KERNEL_RELEASE ?= "${KERNEL_VERSION}"
> # The directory where built kernel lies in the kernel tree
> KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"
> KERNEL_IMAGEDEST ?= "boot"
> +KERNEL_IMAGEDEST_USE_UPDATE_ALTERNATIVES ?= "0"
We should add documentation around the new variable as well, even if
the existing variables aren't fully documented .. we can start a trend
of being better.
Cheers,
Bruce
>
> #
> # configuration
> --
> 2.31.1
>
>
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156432):
https://lists.openembedded.org/g/openembedded-core/message/156432
Mute This Topic: https://lists.openembedded.org/mt/85925303/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
