The directory /usr/share/emacs/site-lisp/vm is created when installing the rpm but is not deleted when the rpm is uninstaled. This can easily be fixed by adding something like: /usr/share/emacs/site-lisp/vm to the %files directive.
What version of the package is this? In future can I ask you not to remove the text in the bugzilla report form that asks for information on the version, how to reproduce etc - fill it in, it really does help! I can't reproduce it with the currrent package. $ yum install emacs-vm ... $ ls -ld /usr/share/emacs/site-lisp/vm drwxr-xr-x 3 root root 4096 Feb 26 16:04 /usr/share/emacs/site-lisp/vm $ yum remove emacs-vm ... $ ls -ld /usr/share/emacs/site-lisp/vm ls: /usr/share/emacs/site-lisp/vm: No such file or directory Can you look in the directory /usr/share/emacs/site-lisp/vm and see if it is empty after you've removed the emacs-vm package? Have you at any point installed VM by hand rather than thru' rpm?
Sorry for not giving more info. I am using: emacs-vm-7.19-7.fc6 The problem seems to be with only when you also install the emacs-vm-el rpm. Case #1: install emacs-vm only [1353]sudo rmdir /usr/share/emacs/site-lisp/vm [1354]ls -al /usr/share/emacs/site-lisp/vm ls: /usr/share/emacs/site-lisp/vm: No such file or directory [1355]sudo rpm -Uvh /usr/local/downloads/yum/extras/packages/emacs-vm-7.19-7.fc6.i386.rpm Preparing... ########################################### [100%] 1:emacs-vm ########################################### [100%] [1356]sudo rpm -e emacs-vm [1357]ls -al /usr/share/emacs/site-lisp/vm ls: /usr/share/emacs/site-lisp/vm: No such file or directory Case #2: Install emacs-vm and emacs-vm-el [1358]ls -al /usr/share/emacs/site-lisp/vm ls: /usr/share/emacs/site-lisp/vm: No such file or directory [1359]sudo rpm -Uvh /usr/local/downloads/yum/extras/packages/emacs-vm-* Preparing... ########################################### [100%] 1:emacs-vm ########################################### [ 50%] 2:emacs-vm-el ########################################### [100%] [1360]sudo rpm -e emacs-vm emacs-vm-el [1361]ls -al /usr/share/emacs/site-lisp/vm total 16 drwxr-xr-x 2 root root 4096 Feb 26 12:03 ./ drwxr-xr-x 7 root root 4096 Feb 26 12:02 ../
Thanks, that's useful information. In actual fact, this isn't a problem with the emacs-vm packaging as far as I can tell: if I install emacs-vm and emacs-vm-el and then remove the packages in 3 different ways, this is what I see: i) yum remove emacs-vm emacs-vm-el $ ls -ld /usr/share/emacs/site-lisp/vm ls: /usr/share/emacs/site-lisp/vm: No such file or directory ii) rpm -e emacs-vm emacs-vm-el $ ls -ld /usr/share/emacs/site-lisp/vm drwxr-xr-x 2 root root 4096 Feb 26 17:28 /usr/share/emacs/site-lisp/vm iii) rpm -e emacs-vm-el emacs-vm [i.e. order reversed] $ ls -ld /usr/share/emacs/site-lisp/vm ls: /usr/share/emacs/site-lisp/vm: No such file or directory I'm not sure if this is a bug with rpm, or intended (but dumb) behaviour of rpm. I am re-assigning this to rpm. For the benefit of the rpm maintainer, the relevant details of the emacs-vm[-el] packaging are 1) emacs-vm-el is a subpackage of emacs-vm 2) emacs-vm-el contains Requires: %{name} = %{version}-%{release} 3) %files sections for the two packages, where we have previously defined %define pkgdir %{_datadir}/emacs/site-lisp/vm %files %defattr(-,root,root,-) %doc README COPYING %doc %{_infodir}/* %{_bindir}/* %{pixmapdir} %{pkgdir}/*.elc %{initfile} %dir %{pkgdir} %files el %defattr(-,root,root,-) %{pkgdir}/*.el
Hm, it seems that you can't reassign a bug that was reported against Extras to a package in Core. Instead I have cc'd the RPM maintainer to the bug. pnasrat - this report, I think, shows a bug in rpm and the way in which package removal transaction is ordered.
Closing bug, rpm maintainer doesn't care.
Hmmm.... What do you mean by "rpm maintainer" doesn't care? RPM seems to be one of the most fundamental packages in a Fedora distro. I could understand any of the following responses: "Bug to be fixed later" "Low priority bug to be fixed when resources allow" "Not a bug" (if explained why not) but cannot understand why "don't care" is a valid response. I try to keep my system as clean as possible so undocumented and inconsistent (and presumably buggy) rpm removal behavior is not a good thing. If you don't mind, I will take the lead in resubmitting this specifically as a RPM bug (assuming that per your previous note you cc'd the RPM maintainer only and didn't submit it as an explicit RPM bug)
Actually, just as I was about to submit a bug report to the RPM maintainer, I realized that the problem may really be with the emacs-vm packages. The directory "/usr/share/emacs/site-lisp/vm" is included in the %file directive of the emacs-vm package but not in the emacs-vm-el package. Adding the directory to the emacs-vm-el package would likely solve the problem. This explains of course why I only noted the problem when emacs-vm-el was installed. It also probably explains the sensitivity to removal order that you noted. For example in case (iii), you first remove emacs-vm-el so then when emacs-vm is removed subsequently the vm directory is empty so it can be removed. Conversely, in case (ii) when you first remove emacs-vm, the vm directory still contains files from emacs-vm-el so it cannot be removed (though one might have thought that the dependency requirement of emacs-vm-el on emacs-vm would have reversed the order of removal). In any case, can you try adding the vm directory to the %files directive in the emacs-vm-el subpackage? Also, as an unrelated point, are you planning on releasing updated versions on a regular basis to track Robert's ongoing vm development? Thanks
It is against the packaging guidelines for more than one package to own a directory. It *should* be sufficient for a package to require a different package that owns the directory. Having two packages own a directory is not a fix, I'm afraid. Do feel free to file a bug against RPM, but I have never had much luck from the current maintainer, I am afraid. I suspect the rpm maintainer might well say that this is by design anyway (which personally I don't agree with). You can get consistent and desired behaviour by always using yum to remove packages, rather than rpm directly. If you look carefully at the package you'll see I am tracking Robert's as much as I can. Currently I patch 7.19 with Robert's last patch against that codebase. Robert has now stopped issuing patches against 7.19, and is now shipping his own tarball (8.0), but that is currently rather too unstable to ship at this point. Particularly as right now we're in a deep freeze. Once F7 is out of the door I will look at packaging an update for 8.0.
Thanks for the helpful explanation. I didn't realize that two packages couldn't own the same directory. I'm surprised though then that this issue hasn't arisen before. It seems like a rather common and straightforward dependency issue. I also would not think that it would be very hard to fix either. I will try to submit a bug report then when I can. Also thanks for the explanation about updates. I didn't realize that 8.0 was still unstable. If you do end up releasing a version of 8.0 early in the release of FC7, it would be great if you could also back-port to FC6 -- this should be easy (hopefully) since should compile fine for either one.
Jonathan - this bug didn't hit my radar as I filter bugs by component so it was in a different folder. I've only just noticed it from the activity in it from the past day or so. Currently rpm cli doesn't implement erasure ordering, this is something I'll be looking at for rpm 4.5 - but it's quite an invasive change.
Paul - thanks for your input, much appreciated. "Need Real Name" - I think that answers your question - it will be addressed in the future.