Re: Bug#61167: emacsen-common: major bug in policy (not RC for potato)
OK, so after all the back an forth about whether or not add-on
packages should just be responsible for cleaning up after themselves,
which I believe was concluded with a "yes", Julian recently did a nice
job of reminding me that there was still a real, honest-to-gooness
nasty problem with the current setup.
After some consideration, I think we have a good solution, but before
implementing it (and changing Debian Emacs Policy) I wanted to see if
anyone can see any problems with the proposed fix.
I've included Julian's thorough description of the problem below, but
in short, right now policy says that emacs20, for example, should
create
/usr/share/emacs20/site-lisp -> ../emacs/20.7/site-lisp
and that add-on packages are free to place files in
/usr/share/emacs20/site-lisp
This is good from the perspective that the add-on packages don't have
to know which particular sub-version of emacs they're installing the
files for, but the symlink itself is very bad.
The problem is that when we go from say 20.7 to 20.8, any add-on
packages that had files installed in emacs20/site-lisp, lose all track
of those files when the new emacs20 changes the symlink to point to
../emacs/20.8. These files effectively vanish as far as the add-on
packages (and dpkg) are concerned.
To fix this, it seems like maybe we can just change policy (and the
relevant emacsXX packages) to reverse the direction of the symlink(s),
so then we'd have
/usr/share/emacs/20.7/site-lisp -> ../emacs20/site-lisp
Does this seem like a suitable solution?
Thanks (and thanks to Julian for his persistence in the face of my
distraction :>).
Julian Gilbey <J.D.Gilbey@qmw.ac.uk> writes:
> On Mon, Apr 02, 2001 at 09:11:27AM -0500, Rob Browning wrote:
>
> > Maybe I'm misunderstanding, but during the emacsen-common script
> > remove step called by the prerm for emacs20 20.3, the add-on package
> > should have cleared out the 20.3 directory. Then the add-on package
> > should re-create its data during the emacsen-common install step
> > called by emacs20 20.4's postinst. If the add-on package does this,
> > then there won't be any cruft.
> >
> > Am I missing the point?
>
> I think so. The emacs policy allows for add-on packages which are
> specific to a particular flavor of emacs. So consider the
> hypothetical package foo-el, which only works with emacs20. It will
> install packages, following the emacs policy, into:
>
> /usr/share/emacs20/site-lisp/foo-el
>
> Now, /usr/share/emacs20/site-lisp is actually a symlink to
> /usr/share/emacs/20.7/site-lisp, which means that foo-el, when it is
> installed, places its .el files in
>
> /usr/share/emacs/20.7/site-lisp/foo-el
>
> as dpkg follows symlinks.
>
> (I've just realised something new: if emacs20 is not yet installed
> when foo-el is unpacked, as it need not be for a Depends, unpacking
> foo-el will create a *directory* /usr/share/emacs20/site-lisp, causing
> all sorts of problems when emacs20 later comes along and tries to
> create a symlink /usr/share/emacs20/site-lisp -> .... So foo-el
> must actually Pre-Depend on emacs20 in this setup.)
>
> Anyway, back to the plot. The install script then runs, placing the
> .elc files and whatever else in
> /usr/share/emacs/20.7/site-lisp/foo-el.
>
> Now, let's upgrade emacs20 to version 20.8-1, and watch what happens:
>
> (1) The prerm emacs clean script runs, and foo-el dutifully removes
> all of the .elc files it created from
> /usr/share/emacs/20.7/site-lisp/foo-el.
>
> (2) Emacs now replaces the /usr/share/emacs20/site-lisp to point to
> /usr/share/emacs/20.8/site-lisp and tries to reinstall all of the
> add-on packages by running their install scripts.
>
> But now see what's happened to foo-el: it's .el files, which are
> listed in the dpkg database as being in
> /usr/share/emacs20/site-lisp/foo-el are no longer there: they've
> become trapped in /usr/share/emacs/20.7/site-lisp/foo-el, as the
> symlink has changed under its nose! So foo-el doesn't know where it's
> .el files are any more, and therefore will no longer be usable. The
> only way to resurrect foo-el is to remove and reinstall it; even this
> won't get rid of the original version stuck in the 20.7/site-lisp
> directory, though.
>
> Does this make the issue a little clearer? It's a fundamental problem
> in the current setup, which will cause the above problems if any
> package ever uses this. As far as I can tell, there is no emacs20
> package doing this at present, but if there ever is, this'll blow up
> in our faces. So it needs fixing first. I did make a few suggestions
> as to how to solve this problem, but I'm not sure that any of them
> work.
>
> Julian
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
> Debian GNU/Linux Developer, see http://people.debian.org/~jdg
> Donate free food to the world's hungry: see http://www.thehungersite.com/
>
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: