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 <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org