Code:
Preparing to unpack .../21-pve-qemu-kvm_2.9.0-5_amd64.deb ...
Unpacking pve-qemu-kvm (2.9.0-5) over (2.9.0-2) ...
Preparing to unpack .../22-libpve-storage-perl_5.0-14_all.deb ...
Unpacking libpve-storage-perl (5.0-14) over (5.0-12) ...
Preparing to unpack .../23-qemu-server_5.0-15_amd64.deb ...
Unpacking qemu-server (5.0-15) over (5.0-14) ...
Preparing to unpack .../24-pve-manager_5.0-31_amd64.deb ...
Unpacking pve-manager (5.0-31) over (5.0-23) ...
dpkg: warning: unable to delete old directory '/usr/local/share': Directory not empty
dpkg: warning: unable to delete old directory '/usr/local': Directory not empty
Preparing to unpack .../25-proxmox-ve_5.0-21_all.deb ...
Unpacking proxmox-ve (5.0-21) over (5.0-16) ...
Preparing to unpack .../26-pve-kernel-4.10.17-1-pve_4.10.17-18_amd64.deb ...
Unpacking pve-kernel-4.10.17-1-pve (4.10.17-18) over (4.10.17-16) ...Not only is it extremely bad practice for a package to try to remove a directory specified in the Filesystem Hierarchy Standard, packages aren't even supposed to be mucking around in /usr/local in the first place, as that directory is supposed to contain host-specific files, and managed packages are by definition not host-specific.
As my /usr/local/share now only contains two empty directories, I can only assume that the new version of pve-manager corrected this error and moved its file to somewhere more suitable – but, as far as I can tell, no such move is mentioned in the changelog between versions 5.0-23 and 5.0-31.
My questions are thus:
- Was such a move executed?
- If yes, why isn't it mentioned in the changelog?
- If no, why did the package try to remove directories it had no business removing?
- In the future, can I trust Proxmox not to remove arbitrary directories on my system?
