Hi, On Sat, 21 Nov 2009, Mike Hommey wrote: > On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote: > > Currently a package without a patch system needs heavy modifications in > > debian/rules to setup the patch system. So when you want to add a patch in > > debian/patches and not in the .diff.gz, you have to choose a patch system > > in place of the maintainer. > > If there is no patch system when you are NMUing, why would you want to > add one ?
Because you want the patch to be clearly identified and to carry its meta-information. Or because maybe you're applying 2 separate patches in the same NMU upload. > > We're not forcing anyone, we make it easier for people to use that patch > > system and we explain why we think it's a wise choice to consider quilt > > as the default patch system to use when you don't have any specific reason > > to pick one over the other. > > Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0 > (native), which kind of suggests 3.0 (quilt) is being forced down. > That's maybe not what you are thinking, but it's how it feels. Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native packages and 3.0 (quilt) is for all the other who have an upstream tarball + a debian dir. The release goal is only about 3.0 (quilt) because switching from a native source package in format 1.0 to 3.0 (native) will always work and thus requires no preparation work. > OTOH, "dpkg-source -x" should result in the same tree (including the .pc > directory), whatever the status of quilt installation is on the system. > Or if that is not possible without quilt, then dpkg-dev should depend on > quilt. I don't agree with that statement. dpkg-source implements a subset of quilt to work without that tool installed, that subset defines the interface of the source package and it does not include the .pc directory in the general case. If you want that part which is internal to quilt itself, you just have to install quilt. On Sat, 21 Nov 2009, Gerfried Fuchs wrote: > > Currently a package without a patch system needs heavy modifications in > > debian/rules to setup the patch system. So when you want to add a patch in > > debian/patches and not in the .diff.gz, you have to choose a patch system > > in place of the maintainer. > > Heavy modification? What's so heavy on three entries there? Don't be blocked on the heavy, it will of course depends on how the package was built (CDBS, debhelper, dh7, hand-crafted). The point is that you have to choose a patch system in place of the maintainer. You add a quilt build-depends and associated changes when he uses CDBS and would have preferred simple-patchsys. > Sorry, but these additions are next to nowhere "heavy modifications", > that's a bit over overrating, to say the least. Agreed, sorry. > The modifications are implied, but it means that the source format is > already this "heavy modification", on a similarly heavy modification > scale. Additionally, if someone wants to sepearte the patches into > feature-patches instead of one-modification-patch-per-upload they will > have to additionally pull in quilt anyway to work on it properly, Well, they can drop the patch in debian/patches, and add it to the end of debian/patches/series. If quilt is installed, it should work as dpkg-source will use quilt applied to know whether patches needs to be applied. If quilt is not installed, it assumes all patches are applied, so you should also apply the patch. > Alright, thanks for explaining the issue - so for the time, what do you > suggest? Remove the quilt handling? Yes, there's no reason to keep it. > Actually ignore the error that quilt gives (like you suggested on IRC)? No, I did not suggest that. I was confused on why you saw the failure and first thought that it was misusage of quilt. > Or wait until the sbuild fix is applied everywhere? No, by experience that would mean to wait for quite long, despite the efforts of the wanna-build maintainers to get buildd maintainers to update their buildd. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
