[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Master



On Tue, Apr 20, 1999 at 02:17:30AM -0600, Jason Gunthorpe wrote:
> Due to the recent escalation of SCSI problems we have been having on
> master a 2.2 kernel (2.2.6-ac1 actually) has just been installed, which
> required an upgrade to slink in the process. 
... 
> What I would like is if someone can investigate /etc/alternatives and the
> man page dirs and try to figure out why all those broken symlinks are
> there - especially on va - if someone makes a script to fix them that
> would be even more cool..

This is a pretty big deal, and I'm surprised that the issue hasn't been
raised here.  I experienced many broken alternatives symlinks after
upgrading, and I'll explain the problem as I understand it.  (Also, see bug
#33237.  BTW, how can I search for bugs that I submitted?)

Say I upgrade from emacs20 20.2-1 to emacs20 20.3-1.  The first contains
/usr/bin/emacs-20.2, and the second contains /usr/bin/emacs-20.3.  They
register these binaries as alternatives for emacs.  Before the upgrade,
/etc/alternatives/emacs points to emacs-20.2.  During the upgrade,
/usr/bin/emacs-20.2 is removed and /usr/bin/emacs-20.3 is installed.  Then,
emacs20 20.3-1 registers its binary as an alternative for emacs.
update-alternatives notices that /etc/alternatives/emacs points into the
ether (ie, at /usr/bin/emacs-20.2) and decides to 1) delete the bad
alternative and 2) put the emacs alternative into manual mode.  Thus,
/etc/alternatives/emacs is _not_ updated to point to /usr/bin/emacs-20.3 and
remains a broken symlink.

Possible solutions:

- Package maintainers should ensure that alternatives point to files whose
  names will not change when the package is upgraded (for example,
  /etc/alternatives/emacs -> /usr/bin/emacs20 -> /usr/bin/emacs-20.3, or
  just call the binary emacs20).

- If the name of an alternative does change on an upgrade, the package
  scripts should explicitly unregister the old alternative and register the
  new.

- update-alternatives should not revert to manual mode in the case of a
  dangling alternative; instead, it should remove the old alternative and
  install the new one.  (Let me know if you think this is best, and I'll
  file a bug and perhaps work on a fix.)

(I think I have the details a bit wrong for emacs, and in fact the
maintainer may have fixed it, because there are now postinst commands to
remove the old alternatives, and the new alternative points to emacs20.  But
the problem exists for wmaker and expect--see BTS--and almost certainly
others.)

Andrew

-- 
But the GNU Project did one other crucial thing which no one else did: we
made a complete free operating system our explicit goal.
- Richard Stallman


Reply to: