Red Hat Bugzilla – Bug 1282430
Rename /etc/os.release.d to /etc/os-release.d
Last modified: 2015-12-11 13:32:46 EST
Description of problem: The fedora-release rpm provide some files to override variables of /etc/os-release (see http://pkgs.fedoraproject.org/cgit/fedora-release.git/tree/fedora-release.spec#n117) But the directory which has these overrides is named /etc/os.release.d - even if the files within override variables of /etc/os-release (note the dot vs dash). It would be better to rename the dir /etc/os.release.d to /etc/os-release.d to match the semantics.
Agreed. It would be nice to rename this for consistency. Also /usr/lib/os.release.d.
Honestly, I need a more compelling reason than "for consistency" to make this change. It's trickier than one might think to ensure that all of the symlinks get migrated properly to a new directory path (particularly in cases where someone has intentionally removed the symlink in order to drop their own version into /etc) and I'd prefer not to break upgrades for anything short of an actual bug.
Can't we just create a symlink from os-release.d to os.release.d? The thign is that the convention <name> <name>.d/* to override works "everywhere", except for os-release.
How does that help your complaint? We'd now be polluting /usr/lib with *both* pathnames. That just adds confusion in my mind. Also, just off the top of my head, I can cite apache's "conf.d" as not matching your convention. Lastly, I don't disagree with your assertion that this was a mistake. It was actually a typo on my part that got overlooked in patch-review and is now non-trivial to correct. Like I said in my previous comment: it's not worth making this change just for aesthetic reasons. If it solved an *actual problem*, that would be a different situation.
Yes, I know it was a mistake. I still wanted to raise it, because I'd really like to get this consistent - maybe even in the far future. But this dir is not to old, so I wonder how much impact a change had. In the end I agree that it's not fixing a bug.
(In reply to Fabian Deutsch from comment #5) > Yes, I know it was a mistake. I still wanted to raise it, because I'd really > like to get this consistent - maybe even in the far future. > > But this dir is not to old, so I wonder how much impact a change had. > Well, this package is installed on every Fedora system and has effects that include: * How systemctl operates (it reads from /usr/lib/os-release) * How the firewall is set up (it's dependent on the VARIANT_ID field) * Which systemd presets file is used. So screwing this up would have a very significant negative effect on systems. We've already had a couple (minor, fortunately) bugs with the conversion to the drop-dir in the first place and I'd prefer not to fix a non-problem and risk breaking people. > In the end I agree that it's not fixing a bug. Thanks, I know it's annoying. It offends my sense of perfectionism too, but I feel that the risks are too high to justify it.
… Thanks for discussing. I say darn, and move on.
So, I took another look at this today while working on BZ#1288205 and I realized that I probably can manage to convert this over to a better directory with minimal risk. Instead of os-release.d, I think I'm going to change it to /usr/lib/fedora. Here's my reasoning: os-release.d sounds like it should belong with the package that processes os-release (systemd). This is confusing for users. Furthermore, this directory now contains more than just the os-release symlinks: it contains the /etc/issue symlink for server and with BZ#1288205 will also contain edition-specific presets. Given those usages, I think calling it /usr/lib/fedora makes the most sense. It should be much clearer.
https://pagure.io/fedora-release/pull-request/19
I am closing this notabug. there are way too many corner cases that can go wrong, if the change fixed a real issue other than sematics I would be willing to fix it, and deal with any fallout