[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New source package formats now available

* Raphael Hertzog <hertzog@debian.org> [2009-11-21 20:51:51 CET]:
> Hi,
> On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> > * Raphael Hertzog <hertzog@debian.org> [2009-11-21 16:54:36 CET]:
> > >  * even if you don't have any upstream patch right now, next time that
> > >    someone must NMU your package, they can cleanly add a patch (with a
> > >    proper DEP-3 header) without having to modify the build system
> > 
> >  This is nothing new for the 3.0 (quilt) format, this is a reason for
> > any patch system format, so this feels a bit like false-advertising,
> > sorry.
> 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?

include /usr/share/quilt/quilt.make


build-stamp: patch

 Sorry, but these additions are next to nowhere "heavy modifications",
that's a bit over overrating, to say the least.

> With 3.0 (quilt), you don't need to do any such modification... the patch
> system is already available even if not used. That's what this point
> means.

 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,
without having it implied through the build-depends and being guided in
the right direction through README.Source.

> In general it should work, but you're right that we have a problem
> here with the buildds running an old version of sbuild (there are still
> many buildd in that situation) because they do "dpkg-source -x" outside
> of the buildd chroot where quilt is not installed even if you added
> quilt in your build-depends.
> AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
> installed due to build-depends and the .pc directory is then created
> at unpack time.
> >  -) quilt doesn't find any applied patches (because dpkg doesn't create
> > the .pc/ directory structure)
> dpkg-source -x uses quilt if it's installed, so if it's here the .pc
> structure is created.

 Alright, thanks for explaining the issue - so for the time, what do you
suggest? Remove the quilt handling? Actually ignore the error that quilt
gives (like you suggested on IRC)? Or wait until the sbuild fix is
applied everywhere?


Reply to: