The concern I have is that I'd like to upload a very small patch that fixes a security issue to the krb5 package in sid and get it into testing quickly.
I am nervous when I think about including that patch along with a bunch of doc changes. In general, when we're going to break a bunch of builds, we tend to file bugs first, fix the broken packages, and then break the dependency. So, for example we don't do library updates to break a bunch of stuff without first trying to make sure that the broken stuff actually will rebuild against the new library. In this instance, I think the right approach is to introduce a debian-specific patch that turns it into a warning not an error, file bugs against the broken packages. If upstream accepts the issue, then close those bugs. After some reasonable time remove the debian-specific patch if upstream doesn't agree with the issue. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
