Re: ITP: mercurial-buildpackage (for those who care about Mercurial)

[Goswin von Brederlow <goswin-v-b@web.de>]

Jens Peter Secher <jps@debian.org> writes:

> 2009/11/19 Goswin von Brederlow <goswin-v-b@web.de>:
>> Jens Peter Secher <jps@debian.org> writes:
> [...]
>>> Â * Support dpkg source format 3.0.
>>
>> Integration of the hg stacked patches extenstion (don't remember the
>> name, the one giving you qpull/qpush) with 3.0 (quilt) format?
>
> As I see it, there is no need for using Mercurial Queues (mq) with
> mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has
> the same purpose as mq, namely to wrap around quilt to achieve
> automatic patch handling.

Not quite. The Mecurial Queues are under version control. That means
I can check out last months patch series, bisect changes, see who
changed what when and so on. All in a way mercurial users are use to.

> To clarify, assume you have downloaded the sample1 package from
> http://people.debian.org/~hertzog/packages/debsrc3.0 which is in
> format "3.0 (quilt)".  To put it under Mercurial control, do
>
> $ mercurial-initrepo sample1
> $ cd sample1
> $ mercurial-importdsc ../sample1_1.0-1.dsc
> $ vi debian/changelog
> (Add a new entry 1.0-2.)
> (Then hack away on a nice new feature touching a lot of files.)
> $ mercurial-buildpackage
>
> Now dpkg-source will have created a patch file
> debian/patches/debian-changes-1.0-2 containing all your hacks.
>
> When you are satisfied, you can do
>
> $ quilt rename nice-new-feature.diff
>
> to give the patch a better name.
>
> You can then start on another feature, which will again end up as
> debian/patches/debian-changes-1.0-2 until you give it a better name.
>
> Or did you have something else in mind?

That means people have to use quilt and mercurial. With mercurisl
queues you would have only mercurial and the quilt part is hidden.

I'm not saying mercurial queues should be forced onto the user but I
think it would be nice to support them.

>>> Â * Only one repository. Â Branches are used to keep upstream separate.
>>
>> Support for pristine-tar?
>
> Sure, just put place your pristine tarballs in ../ and you are fine. :-)
>
> There is no support for keeping the pristine tarballs in the Mercurial
> repository, and I do not really see any point in doing so: The
> pristine tarball can be retrieved from upstream and/or the Debian
> pool.  But I might have missed some use cases...

pristine-tar does not put the tarball into the repository. It only
stores the delta between taring up the upstream branch and the actual
upstream orig.tar.gz. That way you can clone a repository and build
without first having to go hunting around for the orig.tar.gz.

Please look at it and look how git-buildpackage uses pristine-tar. I
find this feature quite important as it saves a lot of time when
having to do a quick fix for a package.

> Cheers,

MfG
        Goswin