On Thu, 2019-01-31 at 15:50 -0800, Mark Yen wrote:
Apologies for butting in, but I think this can be slightly simpler.
If the blacklist entries are in /lib/modprobe.d instead, then the overrides can just be matching files in /etc/modprobe.d (symlink to /dev/null is fine). This way, the blacklists can be shipped as-is in the rpm, with the %post script dropping in new symlinks for things that are in use (if they don't already exist). Future updates will not need to worry about overwriting things (because we never care about modifications to files in /etc).
If an admin wants to re-blacklist a module that was automatically un-blacklisted, they can copy the file from /lib to /etc (or symlink).
This is basically the same mechanism that udev and systemd uses, according to what looks like the commit that added this functionality¹.
Thanks for your thoughts. I've considered this, and actually started
out this way. It's "cleaner", because distribution-installed files
belong in /lib, not /etc. We would have done it this way if we didn't
consider automatic un-blacklisting of loaded filesystem modules (IOW,
if we didn't take the responsibility to try and avoid making systems
unbootable).
However, _with_ the automatic un-blacklisting in %post, it doesn't go
together well. Here's why:
As you already noted, an empty file or symlink to /dev/null is
sufficient to override a file from /lib/ in /etc/. Therefore we can't
include the /etc/ files in the RPM package, not even as %ghost files
(which would result in 0-byte files, overriding all blackisting). Thus,
the /etc/modprobe.d files would be orphans in the file system, and if
suse-module-tools was ever uninstalled, they'd continue to lurk in
/etc/modprobe.d. No big harm done, but highly unclean. It'd be
acceptable for user-generated overrides, but for files generated in a
%post script, I find it untolerable. The only way to make this work
would have been to _always_ generate the files under /etc, with
"blacklist xyzfs" either commented out (for loaded modules) or not (for
everything else). But if we do that, having the same files under /lib
once more would be utterly pointless (*).
This is how I arrived at the conclusion that it's better to install the
files under /etc, and modify them in place. The logic is similar to
what we do with the "unsupported modules" flag in SLES. It has the
additional benefit that "rpm -V suse-module-tools" quickly shows which
files have been un-blacklisted (only approximately if the user also
changes stuff, but still useful).
Regards
Martin
(*) Actually user-unfriendly, because users might think that simply
removing the blacklist file under /etc/modprobe.d would un-blacklist a
module, which is false if another blacklist file exists under /lib.
--
Dr. Martin Wilck