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

[owner@bugs.debian.org: Bug#29352 acknowledged by developer (Emacs postrm doesn't remove its site-lisp directory)]

This bug report and the response indicates a potential problem with
the emacs policy.  I may easily be wrong, but I don't understand why.
My explanation follows the bug report.  (Please CC replies to me; I'm
not subscribed to debian-emacsen.)

  To: 29352-done@bugs.debian.org
  Subject: Re: Bug#29352: Emacs postrm doesn't remove its site-lisp directory
  From: Rob Browning <rlb@cs.utexas.edu>
  Date: 04 Dec 1999 18:06:51 -0600
  jdg@maths.qmw.ac.uk (Julian Gilbey) writes:
  > Package: emacs20
  > Version: 20.3-5
  > Probably affects other versions as well.
  > When emacs20 is de-installed or upgraded to a version with a different
  > minor number, the /usr/share/emacs/20.x directory will probably not be
  > removed as there will most likely be some junk left in it by other
  > packages.  Since the directory is then defunct, the postrm script
  > should probably finish with
  > rm -rf /usr/share/emacs/${MAJOR}.${MINOR} || true
  Unfortunately, we can't do this.  Some packages that *don't* depend on
  emacsen may have files in there (see
  /usr/doc/emacsen-common/debian-emacs-policy.gz and the info on
  packages with marginal relevance), so we can't delete that directory
  unless it's actually empty.

OK.  I've seen the section in the emacs policy (section 5).  At
present, the only package installing into
/usr/share/<flavor>/site-lisp is emacs-czech for emacs19.

But let's say that package foo installs into
/usr/share/emacs20/site-lisp while emacs20 has minor version 3.  Then
/usr/share/emacs20/site-lisp -> /usr/share/emacs/20.3/site-lisp (symlink) 
at the package installation stage, and so the foo's elisp files are
installed in /usr/share/emacs/20.3/site-lisp.  Then emacs20 is
upgraded to minor version 4, and hey presto, package foo will need
reinstalling for its elisp files to be visible to the new emacs20.
Also, the /usr/share/emacs/20.3/site-lisp directory is outside the
jurisdiction of dpkg, so the files from the original installation of
foo under emacs 20.3 will be left there forever.

This is Not Good(TM).

I would strongly recommend coming up with some way of avoiding this
problem.  Perhaps the following simple strategy would work:

 - remove the /usr/share/<flavor>/site-lisp ->
   /usr/share/emacs/<version>/site-lisp symlink, and replace
   /usr/share/<flavor>/site-lisp with a real directory.  (This must be
   done with extreme care, though, given the nature of dpkg.)

 - add /usr/share/<flavor>/site-lisp to the standard list of
   directories searched.

How does that sound?  (And then emacs20 etc. will be able to
rm -rf /usr/share/emacs/<version> on purging ;-)



  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Reply to: