On Tue, 16 Feb 2010, Santiago Vila wrote: > I have not included the part about moving to 3.0 source format. Sorry, > but I need some time to study that carefully and I need to be confortable > with the format before actually using it for the packages I maintain.
Sure. > [ I wonder if it is acceptable to change source format in a NMU at all ]. It's discutable, if you were using a patch system I would not have changed it. But I find it disgusting to have upstream patches hidden in the .diff.gz and using the new format to avoid that is a correct move IMO. Your source package doesn't contain any meta-information about this patch while with my change, we had the upstream URL of the commit that got reverted and some explanations. > 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. > 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 probably fine but given that the package is essential I would avoid this Breaks for squeeze (hence keeping the patch) and I would drop the patch for squeeze+1 adding the Breaks once the fixed dpkg-dev version is already widely installed. It's also best for partial upgrades. Cheers, -- Raphaël Hertzog -- 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/20100216112827.gc31...@rivendell
