Bug 131496 - alternatives (re)--install does not delete orphaned slave symlinks
alternatives (re)--install does not delete orphaned slave symlinks
Product: Fedora
Classification: Fedora
Component: chkconfig (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Ben Levenson
Depends On:
Blocks: FC4Target
  Show dependency treegraph
Reported: 2004-09-01 15:11 EDT by Ville Skyttä
Modified: 2014-03-16 22:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-05 17:11:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
FC2 typescript demonstrating the bug (1.95 KB, text/plain)
2004-09-01 15:18 EDT, Ville Skyttä
no flags Details
Debian typescript demonstrating the expected behaviour (1.65 KB, text/plain)
2004-09-01 15:18 EDT, Ville Skyttä
no flags Details
Proposed patch (1.85 KB, patch)
2005-05-05 16:43 EDT, Miloslav Trmač
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2004-09-01 15:11:34 EDT
This is a bit hard to explain concisely, but here goes.

Doing an "update-alternatives --install /some/where foo /my/foo ..."
when such an alternative already exists (for same values of
/some/where, foo, and /my/foo), but with _different_ set of --slave
names, the "orphaned" (ie. present in the first update-alternatives
--install, but omitted in the second) slaves are not removed.  After
doing this, the only way to clean them up is to manually remove the
orphaned slave links (as well as files from /etc/alternatives) which
are no longer slaves of anything; even "update-alternatives --remove
foo /my/foo" does not delete them.  (The bug is in --install, not
--remove, though.)

The Debian version of update-alternatives does not have this bug.  It
also has the improvement over the Fedora Core version that doing an
"update-alternatives --display foo" when there are no alternatives for
foo prints "No alternatives for foo.", whereas the FC version prints

I will attach annotated typescripts from a FC2 box and a Debian box;
the FC one shows the current buggy behaviour, and the Debian one the
expected, correct one.

It would be very nice to have this fixed (as well as add the "No
alternatives for foo." message added) at least for FC3, but preferably
also errata for earlier versions as well; we in JPackage are currently
being bitten by this.  Essentially, the bug makes it very hard for
packagers to achieve correct behaviour when some slave alternatives
need to be removed on package upgrades.
Comment 1 Ville Skyttä 2004-09-01 15:18:20 EDT
Created attachment 103361 [details]
FC2 typescript demonstrating the bug
Comment 2 Ville Skyttä 2004-09-01 15:18:59 EDT
Created attachment 103362 [details]
Debian typescript demonstrating the expected behaviour
Comment 3 Ville Skyttä 2004-09-01 15:27:57 EDT
While at it: the update-alternatives manpage symlink is missing from
the package.  Fix:

--- chkconfig.spec~     2004-06-15 20:27:43.000000000 +0300
+++ chkconfig.spec      2004-09-01 22:28:03.589678283 +0300
@@ -67,6 +67,7 @@
 %dir /var/lib/alternatives

 %files -n ntsysv
Comment 4 Miloslav Trmač 2005-05-05 16:43:58 EDT
Created attachment 114068 [details]
Proposed patch

This patch modifies --install to compute the union of the provided slaves and
remove the slaves nobody provides when an alternative is updated.
Comment 5 Bill Nottingham 2005-05-05 17:11:44 EDT
Added in 1.3.20-1 - thanks!

Note You need to log in before you can comment on or make changes to this bug.