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

Re: How to cope with patches sanely

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

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: pgpcg80MKK1EX.pgp
Description: PGP signature

Reply to: