Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
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.
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?
>> * 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...
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
Reply to: