Le Tue, Feb 05, 2008 at 02:16:09PM +0200, Lars Wirzenius a écrit : > Specifically I want "dpkg-source -x" to unpack a source package so that > it is ready for modification, and "dpkg-source -b" to build a new source > package after it's been edited. Patch systems can and should conform to > that, since it's important for those doing archive-wide QA.
Hi Lars, thank you for keeping us focused on the real problem. I have been trying to think about it and still did not find an elegant solution. Suppose that, as discussed earlier, "dpkg-source -x" provides source ready for modification: Case 1: It is because all the changes were in the diff.gz. Case 2: It is because a clean way of applying the contents of debian/patches has been developped and used. In that case, unless "dpkg-source -b" has been similarly engineered to turn the new changes into a new patch, things will fail when "debian/rules clean" calls the unpatch rule and the changes overlap an existing patch. Case 3: It is because the sources have been packed patched. In that case, "dpkg-source -b" is expected to work. Now, let's remember the use case for these scenarii: it is when the packages is modified for NMU or QA. If the NMU'ed package is to go back in the hands of its maintainer (not MIA or so busy that he can not do more than one upload per year, of course), as I wrote earlier, why not simply send a diff in a bug report? Then the work overhead of integrating the changes in the source package goes to the person who chose the packaging workflow. Otherwise, let's sees what happens with Cases 2 and 3. In Case 3, the changes that you would make would be hidden in a diff.gz file that would be bloated by design: it would already contain a mixture of modifications to the source and patches shipped as patches to a patch. For the maintainer, the most efficient tool to recover your changes from this would be a debdiff with the old version, which then calls the question of why just sending a diff instead of producing a new source package would not be enough. The easier scenario is of course the variant of Case 2 in which where a automagic dpkg-source would take care of detecting the patch system and turn your modifications into a new patch. But I have not seen any person volunteer for working on such a modification. So maybe the simplest solution would be the following : - Standardize the name of the patch rule so that "debian/rules patch" does the job. - dpkg-source -b && debian/rules patch - make a diff and send it to the BTS. or, in the case of unmaintained packages: - get rid of the patch system if you think that it is not good for QA work on it. It leaves the problem of trusting the command "debian/rules patch" when working on non-official packages, but as I wrote before, the other targets of debian/rules would have to be audited anyway, so why not checking them first, and then run "debian/rules patch" ? (or decline to sponsor the work of persons storing their changes in debian/patches). Of course, I would be very interested to hear better solution, because as I wrote, this one is not particularly elegant. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
