On 29/01/2008, Daniel Leidert wrote:
> svn-buildpackage is not a framework to create or edit patches. So how
> should it compare to quilt? It "merges" the contents of the
> .orig.tar.gz with the content in SVN and then it builds the package by
> using dpkg-buildpackage/debuild/pbuilder/pdebuild/sbuild/whatever.
From what you've described, it looks like you use dpatch to fetch the
content of the tarball and work on it. That is: sparing a “tar” call.
> Because I don't want to store the whole source in a VCS just to be
> able to maintain a package collaboratively. So quilt should be able to
> do the same for me dpatch does or it is not an alternative. I do not
> consider putting the whole source under VCS as an alternative - it
> increases space needs of the VCS and the checkout size - simply a
> waste of time and resources. Upstream normally has its own VCS to
> store the history of files. Why should we do this on e.g. svn.d.o too?
> If I want to have a look at the history of the file, I can take a look
> into upstreams VCS.
I'm only keeping debian/ under $VCS (svn for pkg-{games,python}, git for
all others) and I only have to invoke tar. uscan is my friend (and
probably later pristine-tar to get any version of the upstream tarball
easily).
Just call tar to extract the tarball, work on your patches using your
preferred patch management system, commit your patches in $VCS and
you're done.
> Yes, I like the debian/-only layout svn-buildpackage offers.
Me too… although you don't need *-buildpackage at all to achieve that.
tar is very sufficient.
--
Cyril Brulebois
Attachment:
pgp80wVQ5g1C8.pgp
Description: PGP signature