severity 508392 serious retitle 508392 Handling of conflicting conffiles broken found 508392 1.14.23 found 508293 1.13.25 thanks
Hi, I reconsidered the severity of this issue and came to the conclusion that this a policy violation. Apart from this it is a regression (although it already entered Etch). So I consider severity serious adequate. To the rationale: The policy declares what the Replaces field is for in [1]. "Firstly, as mentioned before, it is usually an error for a package to contain files which are on the system in another package. However, if the overwriting package declares that it Replaces the one containing the file being overwritten, then dpkg will replace the file from the old package with that from the new." It does not explicitily say that dpkg has to stop, when one package contains files of the other but no Replaces relationship is set, but it says that including a file that is owned by another package without setting a Replaces header is an *error*, which IMHO implicits defines that dpkg would need to stop or at least warn if it is about to replace files of another package. If you disagree, please lower the severity again. But please fix it for Lenny anyway. Having regressions over *two* stable releases in one of our core tools wouldn't really speak for our release quality :( Best Regards, Patrick [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
