Bug#4741: Removing emacs fails if there are files in /usr/local/lib/emacs
Dirk.Eddelbuettel@qed.econ.queensu.ca writes:
->
-> Richard> Package: emacs
-> Richard> Version: 19.34-2
-> Richard>
-> Richard> attempting to 'dpkg -r emacs' fails if any files have been placed
-> Richard> in /usr/local/lib/emacs or /usr/local/lib/emacs/site-lisp. (At
-> Richard> least with dpkg 1.4.0 it does)
-> Richard>
-> Richard> What good is creating an empty directory tree in /usr/local if it
-> Richard> complains if I stick anything in there?
->
-> Come on, this is nothing to do with emacs, but with dpkg. Did you ever
-> install a kernel-source package and tried to remove it after you built a
-> kernel? Same result as all the .depend still hang around which are not in
-> dpkg's list.
->
-> I know you don't like the emacs package to create empty dirs in your
-> /usr/local, but we already discussed this and concluded that emacs and perl
-> are allowed to put empty dirs there.
->
I believe the relevant issue here is not that the directories get
created, but that dpkg tries to manage said directories. It's
certainly acceptable for perl and emacs to create directories in
/usr/local to indicate that this is where local emacs lisp and perl
modules go, but once they're there, but a sysadmin should be able to
do anything they like in /usr/local without giving dpkg indigestion.
The best solution, IMHO, would be to create the directories in a
postinst script, and remove them with a prerm script ONLY IF THEY ARE
EMPTY. That would be an acceptable solution.
-Larry
--
Larry Daffner | Linux: Unleash the workstation in your PC!
vizzie@airmail.net / http://web2.airmail.net/vizzie/
C makes it easy to shoot yourself in the foot. C++ makes it harder, but
when you do, it blows away your whole leg. -- Bjarne Stroustrup on C++
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: