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.
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.
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