We discussed this at today's committee meeting. We noticed that the spec file links in those review tickets currently do not work (404 not found). While a full review may be unnecessary, we would at least like to take a look at the new spec files to ensure the upgrade path makes sense.

@carlwgeorge Thanks for bringing this ticket to discussion! The spec file links work now (sorry I uploaded the spec files to the wrong place i.e. "public_html:" instead of "public_html").

In case you need to review the new kexec-tools' spec file, here is the link https://coiby.fedorapeople.org/kexec-tools.spec. When users update the system, the kexec-tools will be updated to the split kexec-tools but users will see a message that they need to install kdump-utils if they need the kdump feature.

The main issue I see right now is that the new packages don't conflict with existing versions of kexec-tools. A user could have kexec-tools-2.0.27-1 installed, not having upgraded to kexec-tools-2.0.27-2 yet, and try to install kdump-utils-1.0.42-1 or makedumpfile-1.7.3-1. dnf would allow the transaction to start, but then it would fail before completion due to file level conflcits on /usr/sbin/mkdumprd, /usr/sbin/makedumpfile, or other files. The fix for this is to add the following directive to the new packages:

Conflicts: kexec-tools < 2.0.27-2

With that explicit conflicts directive, in the scenario above dnf will upgrade kexec-tools in the same transaction to avoid the conflict.

In case you need to review the new kexec-tools' spec file, here is the link https://coiby.fedorapeople.org/kexec-tools.spec.

I'm diffing this locally after downloading the spec file, but to help others see the changes easier can you post this as a pull request to the kexec-tools distgit repo? You can prefix the subject with "WIP:" to indicate to others that it's not ready to be merged until the new packages are added.

When users update the system, the kexec-tools will be updated to the split kexec-tools but users will see a message that they need to install kdump-utils if they need the kdump feature.

While not explicitly banned, using scriptlets to print messages for the user in the terminal is generally frowned upon. The message won't be seen at all if the user updates the package through something else besides dnf, such as GNOME Software or an ansible playbook. Even if the user updates with dnf in the terminal, a printed message like this is really easy to miss. My suggestion instead would be to add the following directives to the new kexec-tools:

Recommends: kdump-utils
Recommends: makedumpfile

This means that by default kexec-tools will pull in the new packages as weak dependencies, giving users the same commands before and after the update. Users can then optionally uninstall the weak dependencies. Alternatively, both of the new packages could use Supplements: kexec-tools, which has the same effect.

The main issue I see right now is that the new packages don't conflict with existing versions of kexec-tools. A user could have kexec-tools-2.0.27-1 installed, not having upgraded to kexec-tools-2.0.27-2 yet, and try to install kdump-utils-1.0.42-1 or makedumpfile-1.7.3-1. dnf would allow the transaction to start, but then it would fail before completion due to file level conflcits on /usr/sbin/mkdumprd, /usr/sbin/makedumpfile, or other files. The fix for this is to add the following directive to the new packages:

Conflicts: kexec-tools < 2.0.27-2

With that explicit conflicts directive, in the scenario above dnf will upgrade kexec-tools in the same transaction to avoid the conflict.

Thanks for pointing out the possible conflicts of package files and also providing the solution! I considered the conflict of /usr/sbin/mkdumprd but neglected the conflict of /usr/bin/makedumpfile. I'll add "Conflicts: kexec-tools < 2.0.27-2" to makedumpfile.spec (kdump-utils doesn't need it because I already added "Requires: kexec-tools >= 2.0.27-2").

In case you need to review the new kexec-tools' spec file, here is the link https://coiby.fedorapeople.org/kexec-tools.spec.

I'm diffing this locally after downloading the spec file, but to help others see the changes easier can you post this as a pull request to the kexec-tools distgit repo? You can prefix the subject with "WIP:" to indicate to others that it's not ready to be merged until the new packages are added.

Thanks for the suggestion! I've created https://src.fedoraproject.org/rpms/kexec-tools/pull-request/17

When users update the system, the kexec-tools will be updated to the split kexec-tools but users will see a message that they need to install kdump-utils if they need the kdump feature.

While not explicitly banned, using scriptlets to print messages for the user in the terminal is generally frowned upon. The message won't be seen at all if the user updates the package through something else besides dnf, such as GNOME Software or an ansible playbook. Even if the user updates with dnf in the terminal, a printed message like this is really easy to miss. My suggestion instead would be to add the following directives to the new kexec-tools:

Recommends: kdump-utils Recommends: makedumpfile

This means that by default kexec-tools will pull in the new packages as weak dependencies, giving users the same commands before and after the update. Users can then optionally uninstall the weak dependencies. Alternatively, both of the new packages could use Supplements: kexec-tools, which has the same effect.

Thanks for explaining the problems of using scriptlets to print messages and offering a much more elegant solution:) Despite that RHEL discourages week dependencies in BaseOS, I think this case can be completely justified or RHEL can simply remove "Recommends: kdump-utils" as kdump-utils will be BaseOS as well . Since kdump-utils requires makedumpfile, I only add "Recommends: kdump-utils" to kexec-tools.spec.

I was hoping we could do the review exception, but this change seems to quite a bit more involved that I initially expected. To me it's clear that it would benefit from a full review process. We can continue the discussion in the review bugs.