Package: ca-certificates Version: 20061027 Severity: serious Justification: Policy 6.2 (sometimes interacts non-idempotently), 3.9 (error (missing dir) not checked for), 6.8 (removes files at wrong time)
The postrm, called with "remove", changes into a directory that does not always exist. The results are unpleasant. 1. if you try to remove the package when /etc/ssl/certs is empty, remove fails, because dpkg removes the dir before postrm is called 2. if you removed but did not purge (typical within aptitude, because such packages as openoffice.org-core pull you in automatically) and later try to remove or purge again, remove/purge fails. I believe you MUST be able to remove a package more than once, idempotently (policy 6.2), but currently, you cannot. Hence I think the bug is serious. (Apologies if I'm wrong about that.) For example, dpkg can't always remove the package if brokenly installed. Encountered during sarge -> etch upgrade error recovery: wolfgang:~# dpkg -r ca-certificates (Reading database ... 114332 files and directories currently installed.) Removing ca-certificates ... /var/lib/dpkg/info/ca-certificates.postrm: line 21: cd: /etc/ssl/certs: No such file or directory dpkg: error processing ca-certificates (--remove): subprocess post-removal script returned error exit status 1 Errors were encountered while processing: ca-certificates Possible solutions: 1. in postrm, check if dir exists before cd; or 2. create a prerm and remove the hash symlinks there The second seems more in keeping with policy 6.8: the prerm should do the cleanup, then dpkg can remove the dir /etc/ssl/certs listed in *.list (and we won't get warnings about dir not empty) Perhaps the dir is only empty if you answer the template question the same way I did? It might explain why this hasn't been noticed before. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
