On Wed, Jun 21, 2023 at 11:38:37PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 19, 2023 at 03:31:27PM +0800, Coiby Xu wrote:
> Related:
https://bugzilla.redhat.com/show_bug.cgi?id=2121912
>
> Now there is a growing user base to use the kexec reboot and it's
> desirable to make the kexec-tools package more modular.
>
> This patch splits current kexec-tools into two sub-packages kexec-tools
> and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the
> remaining features go into kdump-tools.
Maybe submit this as PR against the dist-git repo? We'll get a test
build then.
Thanks for the suggestion! I'll submit a PR against the dist-git repo
for next version.
> +Obsoletes: kexec-tools = 2.0.26-8
I don't think strict equality can be every satisfied.
Oh, I meant Provides. Quoting
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-re...,
If a package is being renamed without any functional changes, or is a
compatible-enough replacement to an existing package (where "enough" means that
it includes only changes of magnitude that are commonly found in version upgrade changes),
provide clean upgrade paths and compatibility with:
Provides: oldpackagename = $provEVR
Obsoletes: oldpackagename < $obsEVR
I assume at least majority of the users install kexec-tools for the
kdump feature so I kdump-tools is a compatible-enough replacement to the
old kexec-tools.
> +BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison
flex lzo-devel snappy-devel libzstd-devel
> +BuildRequires: pkgconfig intltool gettext
> +BuildRequires: systemd-rpm-macros
> +BuildRequires: automake autoconf libtool
> +Obsoletes: diskdumputils netdump kexec-tools-eppic
One-per-line is the usual recommended style.
I'll use one-per-line for next version, thanks!
> -%post
> +%post -n kdump-tools
> # Initial installation
> %systemd_post kdump.service
This one is tricky. %systemd_post presets the service on "first installation",
which is actually the first the time package is installed. I.e. it unfortunately
also would execute the preset on upgrades that split out a subpackage, because
as far as rpm is concerned, this is the initial installation of that subpackage.
The righteous way to solve this would be something like this:
%triggerprein -n kdump-tools -- kexec-tools < 2.0.26-8
touch %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset
%post -n kdump-tools
rm %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset 2>/dev/null && return
0
# Initial installation
%systemd_post kdump.service
A bit of a bother, but at least nobody will be suprised by
kdump.service changing state.
Thanks for catching this issue and also providing a fix! I'll apply it
to next version.
Zbyszek
--
Best regards,
Coiby