Package: blktap-dkms Version: 2.0.91-1 Severity: important User: [email protected] Usertags: piuparts
Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. >From the attached log (scroll to the bottom...): Removing blktap-dkms ... -------- Uninstall Beginning -------- Module: blktap Version: 2.0.91 Kernel: 3.2.0-4-amd64 (x86_64) ------------------------------------- Status: Before uninstall, this module version was ACTIVE on this kernel. blktap.ko: - Uninstallation - Deleting from: /lib/modules/3.2.0-4-amd64/kernel/../extra// - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. depmod.... DKMS: uninstall completed. ------------------------------ Deleting module version: 2.0.91 completely from the DKMS tree. ------------------------------ Done. [...] 1m1.4s ERROR: FAIL: Package purging left files on system: /lib/modules/3.2.0-4-amd64/kernel/ not owned I recently patched dkms to (try to) remove the directories it created in /lib/modules/*/ to install the kernel modules. This works fine for all packages except blktap-dkms which uses DEST_MODULE_LOCATION="/kernel/../extra/" in its dkms.conf, while all other -dkms packages use a path without a '..' component. The "extra" directory gets cleaned up, but the "kernel" directory is not, and I don't want to enhance dkms to handle '..' in these paths. Please change this to DEST_MODULE_LOCATION="/extra" (although I would prefer DEST_MODULE_LOCATION="/updates/dkms", but I'm afraid dkms wouldn't handle this as a smooth transition) cheers, Andreas
blktap-dkms_2.0.91-1.log.gz
Description: GNU Zip compressed data
