Bug 131496 - alternatives (re)--install does not delete orphaned slave symlinks
Summary: alternatives (re)--install does not delete orphaned slave symlinks
Alias: None
Product: Fedora
Classification: Fedora
Component: chkconfig   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Ben Levenson
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
Reported: 2004-09-01 19:11 UTC by Ville Skyttä
Modified: 2014-03-17 02:47 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-05 21:11:44 UTC
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 19:18 UTC, Ville Skyttä
no flags Details
Debian typescript demonstrating the expected behaviour (1.65 KB, text/plain)
2004-09-01 19:18 UTC, Ville Skyttä
no flags Details
Proposed patch (1.85 KB, patch)
2005-05-05 20:43 UTC, Miloslav Trmač
no flags Details | Diff

Description Ville Skyttä 2004-09-01 19:11:34 UTC
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 19:18:20 UTC
Created attachment 103361 [details]
FC2 typescript demonstrating the bug

Comment 2 Ville Skyttä 2004-09-01 19:18:59 UTC
Created attachment 103362 [details]
Debian typescript demonstrating the expected behaviour

Comment 3 Ville Skyttä 2004-09-01 19:27:57 UTC
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 20:43:58 UTC
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 21:11:44 UTC
Added in 1.3.20-1 - thanks!

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