Re: How to cope with patches sanely
Am Dienstag, den 29.01.2008, 08:38 -0500 schrieb David Nusinow:
> On Tue, Jan 29, 2008 at 02:09:29PM +0100, Daniel Leidert wrote:
> > > And to answer the original question, sure, quilt can handle it; as well as
> > > any patch management system can handle the fact that the things you're
> > > applying the patches against are external to the VCS and require rain dances
> > > of one sort or another to facilitate patch editing.
> >
> > http://www.wgdd.de/?p=25 is some sort of "rain dance"? Oh well, are you
> > kidding me? All I want to know is, if quilt can do the same. Then I will
> > give it a try. If it cannot handle this design, well then it's not an
> > alternative for me. Why should I mirror the upstream VCS and blow up
> > svn.d.o or my own VCS servers?
>
> That link is fairly complicated in comparison to any scheme I've ever used,
I don't know the needs of X.org package maintenance.
> so yes, I'd personally say that Steve's characterization is accurate.
Ok, so JFTR: I do not agree to Steves characterization.
> Many
> of us just have to clone/checkout the sources as you would any other and
> start working.
There is not much difference. You just need a proper dpatch setup ad
the .orig.tar.gz. I don't think, the latter is a problem for package
maintainers. And about the proper dpatch setup: Well, I blogged about
how to set a general path to the .orig.tar.gz. The definition of
PACKAGENAME and UPSTREAMVERSION was necessary, because the dpatch
scripts determined these variables too late, so I had to set them
earlier (in the config file). If the situation changed, the whole config
file would look like this (for me):
____________________ .dpatch.conf ____
/
conf_origtargzpath="/usr/local/src/packages/${PACKAGENAME}"
\______________________________________
Defining a legal variable in a config file is a "rain dance"?
> At any rate, the quilt scripting does not have any special hooks to grab
> external .orig.tar.gz's. This should be trivial to script if you really
> want it, but doesn't svn-buildpackage or whatever it is people are using
> these days to do this sort of thing provide a way to get it anyhow?
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.
> Why do you need quilt to do it for you?
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.
Yes, I like the debian/-only layout svn-buildpackage offers.
Regards, Daniel
Reply to: