On Tue, 16 Feb 2010, Raphael Hertzog wrote: > > BTW: I have not closed the bug in the upload, as I'm not convinced > > that it's a bug in diffutils: If you write a program (dpkg-dev) which > > relies on the console output of another progam (diff), being that a > > dangerous thing, then you should be ready to change the first program > > whenever the console output of the second program changes. > > It depends on whether you consider the output part of the official API > of the tool. It's still a bug that affects us and I don't see why you > would not close it with this upload even if upstream (and you) decide > to not revert it definitely in the long term.
That dpkg and diffutils 2.9-1 can't work together is obvious. That such fact is due to a bug in diffutils is what I'm unsure about. My idea was to reassign the bug back to dpkg-dev so that you can close it whenever it's adapted to the new diff behaviour. > > I also do not understand the blurb you included in the changelog for > > the NMU. Why can't we fix this in squeeze? We have Depends and Breaks. > > I guess some combination of that will work, unless there is something > > I'm missing. > > The only combination that works is adding "Breaks: dpkg-dev (<< version of > dpkg that knows the new output)". But it also means that the upgrade > between diffutils (essential package) and dpkg-dev/dpkg needs to be done > in a given order (dpkg-dev/dpkg first). > [...] > It's also best for partial upgrades. I don't consider that a problem at all. Lots of packages in squeeze depend on packages only in squeeze. Not every partial upgrade from lenny to squueze is supported, only the ones that satisfy the dependencies, the conflicts, and the breaks. For example, new packages in testing used to depend on new libc6 in testing (the clever dpkg-shlibdeps behaviour makes this to be a bad example, but for a while just think about the old days) which means: * If you upgrade packake "foo" which depends on the new libc6, you have to upgrade libc6 as well. That was a normal thing and nobody postponed libc6 nor package "foo" to testing+1 to avoid it. What we have now is: * If you upgrade diffutils which breaks dpkg-dev, you have to upgrade dpkg-dev as well (if you have it installed at all). I see these two examples very similar. If the first one is acceptable and normal, so it should be the second one, IMHO. To summarize: Please let us fix this in squeeze if we can, just like any other bug, I don't see a good reason to delay it intentionally. BTW: You might want to contact upstream by using the new list "bug-diffutils.gnu.org" that now exists. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1002161233450.26...@cantor.unex.es
