Fix missing dkms modules after upgrades (try 2)

[tonyhutter]

Motivation and Context

Make dkms upgrades work correctly when upgrading Fedora. This PR is a refactored version of #8160.

Description

If you were upgrading from say, fc28->fc29, on ZFS version X, the RPMs macros would get called like this:

%post X.fc29
   - This is the step where fc29 gets built by dkms.
     As part of the build, dkms automatically removes the previous
     modules before building the new ones.  It then builds the new
     modules.
%preun X.fc28
   - Right before this step, X.fc29 is be built and installed, but
     since it has the same X, it's files get inadvertently removed
     by fc28's uninstall.
%postun X.fc28

This has the unfortunate side effect that the newly built f29 modules get removed by the f28 %preun step, giving you no modules.

This patch updates %preun X.fc28 to see if we're upgrading or uninstalling. If we're uninstalling, then remove our files. If we're upgrading, check to see if were updating to a new version (0.7.11 -> 0.7.12) or upgrading the same version to a new OS (zfs-dkms.0.7.12.fc28 -> zfs-dkms.0.7.12.fc29). If we're upgrading versions then uninstall the old files. If we're upgrading the OS, then do nothing, since we know our old modules are just going to get overwritten when they're rebuilt for the new OS.

Fixes: #6902

How Has This Been Tested?

Did some unit tests using a reproducer similar to (#8089 (comment)). Also did the following:

1. Installed pristine Fedora 28.
2. Installed dkms packages with this fix.
3. Upgraded to Fedora 29.
4. Verified that dkms modules recompiled and worked on Fedora 29.

Also:

1. Installed 0.7.12 dkms packages with this fix on Fedora 29.
2. Installed newest dkms containing a needed fix (dell/dkms#60).
3. Upgraded to fake "0.7.13" dkms packages correctly.

Types of changes

• [1] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.

[Conan-Kudo]

This is more complicated than it needs to be. Just use --rpm_safe_upgrade on dkms add and dkms remove .

Cf. https://www.mankier.com/8/dkms#--rpm_safe_upgrade

[codecov]

Codecov Report

Merging #8216 into master will decrease coverage by 0.15%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8216      +/-   ##
==========================================
- Coverage   78.56%   78.41%   -0.16%     
==========================================
  Files         379      378       -1     
  Lines      114924   114759     -165     
==========================================
- Hits        90286    89983     -303     
- Misses      24638    24776     +138

Flag	Coverage Δ
#kernel	78.73% <ø> (-0.11%)	⬇️
#user	67.32% <ø> (-0.35%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c87db59...9e347b2. Read the comment docs.

[tonyhutter]

@Conan-Kudo we already use --rpm_safe_upgrade on remove. We don't use dkms add, but rather /usr/lib/dkms/common.postinst to build the modules, since that's what dkms does in their template spec file (https://github.com/dell/dkms/blob/master/template-dkms-mkrpm.spec).

[Conan-Kudo]

@tonyhutter So then, this is just logic for dealing with updated releases of the same version? When do we ever do that? Aside from distro upgrades, obviously...

[tonyhutter]

@Conan-Kudo correct. It's for upgrading the same zfs version between OSs (zfs-dkms-0.7.12.fc28 -> zfs-dkms.0.7.12.fc29).

[behlendorf]

The logic here looks sound to me, though I didn't manually verify this fix.

[behlendorf]

The logic here looks sound to me, though I didn't manually verify this fix.

[behlendorf]

@Lalufu would you mind reviewing this fix.

[Lalufu]

The logic looks OK to me, but I believe printing stuff in scripts is frowned upon.

[behlendorf]

@Lalufu good point. @tonyhutter let's get this refreshed without the extraneous logging.

[Lalufu]

FTR, I just updated from F29 (running kernel-5.0.9-200.fc29.x86_64) to F30 (running kernel-5.0.9-301.fc30.x86_64), using spl-dkms-0.7.13-1.fc29.noarch and zfs-dkms-0.7.13-1.fc29.noarch, and ended up without SPL and ZFS modules in the F30 system.