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

Re: New source package formats now available



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


Reply to: