ITP: mercurial-buildpackage (for those who care about Mercurial)
Jens Peter Secher
maintenance you should try out mercurial-buildpackage in
http://people.debian.org/~jps/squeeze/ .
I have spent some time on making an improved version of
hg-buildpackage, which turned out to become a complete rewrite now
called mercurial-buildpackage. The highlights are
* Support dpkg source format 3.0.
* Several .dsc can be imported to retain the full history when
converting an existing package.
* Building via pbuilder is a breeze.
* Easily parsable output; same format as Lintian or Piuparts.
* Complains if the repository has uncommited changes (unless --force).
* Only one repository. Branches are used to keep upstream separate.
I will now work on getting backporting, downstreaming (Ubuntu etc.) to
be a breeze (breezy?) too.
Cheers,
--
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Goswin von Brederlow
> Executive summary: If you use Mercurial and pbuilder for package
> maintenance you should try out mercurial-buildpackage in
> http://people.debian.org/~jps/squeeze/ .
>
> I have spent some time on making an improved version of
> hg-buildpackage, which turned out to become a complete rewrite now
> called mercurial-buildpackage. The highlights are
>
> * 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?
> * Several .dsc can be imported to retain the full history when
> converting an existing package.
>
> * Building via pbuilder is a breeze.
>
> * Easily parsable output; same format as Lintian or Piuparts.
>
> * Complains if the repository has uncommited changes (unless --force).
>
> * Only one repository. Branches are used to keep upstream separate.
Support for pristine-tar?
> I will now work on getting backporting, downstreaming (Ubuntu etc.) to
> be a breeze (breezy?) too.
>
>
> Cheers,
Much appreciated.
MfG
Goswin
Jens Peter Secher
>> * 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?
Goswin von Brederlow
> 2009/11/19 Goswin von Brederlow <goswi...@web.de>:
>> Jens Peter Secher <j...@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
Jens Peter Secher
> Jens Peter Secher <j...@debian.org> writes:
>> 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.
Hmm, the debian/patches/ are also under version control.
I am afraid I still do not see a real difference...
> All in a way mercurial users are use to.
...except for the above (assuming Mercurial really are used to MQ).
>
> 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.
Sure, but I do not know how to do that at the moment. :-)
>
> 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.
Heh, I started implementing support for pristine tarballs yesterday,
but now I realise that pristine-tar is a package. Well, that makes
things a lot easier. I will incorporate it.
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?
Goswin von Brederlow
> 2009/11/21 Goswin von Brederlow <goswi...@web.de>:
>> 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.
>
> Heh, I started implementing support for pristine tarballs yesterday,
> but now I realise that pristine-tar is a package. Well, that makes
> things a lot easier. I will incorporate it.
>
> Cheers,
Hehe, it sure does. Didn't mean you should invent the wheel again. :)
MfG
Goswin
Darren Salt
> 2009/11/21 Goswin von Brederlow <goswi...@web.de>:
>> Jens Peter Secher <j...@debian.org> writes:
>>> 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. [...]
*May* be under version control. If so, it's a separate repository; and if you
want it to be public, you have to push it separately (I don't see equivalents
of 'push', 'pull', 'in' and 'out' there short of using --cwd).
[snip]
> Hmm, the debian/patches/ are also under version control.
That directory *will* be, yes.
> I am afraid I still do not see a real difference...
It looks like something like the following will work:
* make .hg/patches a symlink to debian/patches;
* add debian/patches/status and debian/patches/guards to .hgignore;
* require that .hg/patches/series is quilt-compatible (no guards);
* require that .hg/patches/guards is empty or non-existent;
* deapply patches at build time ("hg qpop --all"; abort build on failure).
(No, I don't have a patch for this.)
>> All in a way mercurial users are use to.
> ...except for the above (assuming Mercurial really are used to MQ).
I've made some use of that where I use mercurial; better that than quilt,
given the integration into mercurial.
>> That means people have to use quilt and mercurial. With mercurisl
>> queues you would have only mercurial and the quilt part is hidden.
Agreed.
>> I'm not saying mercurial queues should be forced onto the user but I
>> think it would be nice to support them.
I'm not sure that quilt should be forced onto the user unless it's properly
integrated into the VCS; and where the VCS has its own patch queue
management, that should be preferred.
> Sure, but I do not know how to do that at the moment. :-)
See above (probably). :-)
[snip]
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + http://wiki.debian.org/DebianEeePC/
Happiness adds and multiplies as we divide it with others.