fedora-sysv
Ignore alternatives that are binary-identical to existing ones
In https://bugzilla.redhat.com/show_bug.cgi?id=2363937 we found a problem that is ultimately triggered by alternatives configs having multiple entries that point to the same binary, or the same effective binary after /usr and /sbin merges (which is what streq_bin handles). I can't see a reason why we'd ever want to support this as a real thing, so when reading the config, let's just skip ingesting any alternative whose leader target is the same effective binary as an alternative we've already read.
we might also want to add something to not add binary-equal alternatives into the config file in the first place, but it seemed more important to do this, since we know there are systems already out there in the wild that have them. We could also actually go ahead and wipe dupe entries from the config file when we encounter them, but that seems more radical (and I don't know how to do it properly/safely, I'm not really a C coder.)
The known consequences of this, btw:
- The identical alternatives show up in e.g.
--configand--display, which looks weird and confusing - It causes
alternatives --initscriptto disable the service when run, because when it iterates over any duplicate after the first, it will realize it's not the 'current' alternative and disable its service, which is of course the same service as the 'current' alternative. That's the bug that was reported downstream
Sorry, I was away last week. If the problem is the duplicate entries, this might go deeper. I could imagine that you would have the same problem when removing such an alternative, which this patch does not cover
The existence of duplicate entries is the root of all the problems, I'd say, yeah. (Where we define 'duplicate' as 'entries with the same leader binary, after resolving symlinks').
It's possible the other recent changes here have made it so we'll no longer create duplicate entries. It's hard to be sure, there's a lot of moving parts and I don't actually have a clear way to reproduce the bug 'naturally' (I've been reproducing it by hand-editing the data file). But from the bug report it's clear that there are real-world users who've got duplicate entries, so we do need to handle that situation somehow.
If you can come up with something that detects and removes duplicate entries reliably and consistently that should also resolve the problems, I believe.
@lnykryn still, I would like to push this fix to stable for Fedora for now, to stop people running into the problem. Do you think it's OK to push https://bodhi.fedoraproject.org/updates/FEDORA-2025-aa88a0d00b and https://bodhi.fedoraproject.org/updates/FEDORA-2025-bbaef37b87 - which have this backported - stable now, so people stop hitting the upgrade problem, then we can do more comprehensive change later? Thanks.
Yeah, go ahead. That will fix the symptoms. I think I have an idea how to handle this a bit more definitely, but it is still work in progress https://github.com/lnykryn/chkconfig/commit/7a627d496639e4ed5b06af90962b83f1e9942153