How to cope with patches sanely

David Nusinow dnusinow at speakeasy.net
Sat Feb 23 16:20:55 UTC 2008


On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
>         Now, you are trying to make me go towards a mechanism I think is
>  inferior (a liner, dependent, and in my opinion, opaque, and somewhat
>  shaky linear patch series) as opposed to pure, independent feature
>  branches, for benefits I still think are dubious, so expect serious
>  push back.  Especially if for every upload I'll have to redo all the
>  integration work of the past; ain't gonna happen.
> 
>         I am not trying to convince you of the error of your ways.
>  Please desist trying to convince me of mine.

No one, not me, nor anyone else in this thread that I've seen, is saying
that you should abandon your sytem. What we want is a consistent method of
dealing with differences from upstream. Currently, we have one giant
.diff.gz, which people hack around either with patch systems or vcs's. If
we switch to something other than a monolithic .diff.gz on top of a
.orig.tar.gz, then we win because currently we just have a lot of chaos.

No matter what you want to say about your feature branches, you *must*
apply them in a linear fashion to your final source tree that you ship in
the package. This is no way around it. This idea, a linear stack of changes
one on top of the other, is the commonality between every one of the
different means of handling changes to upstream, be they maintained by a
patch system or a vcs. What we want is to stanardize this concept so that
our general tools like dpkg are aware of it.

Given what I know about your system, the only change you would have to make
is that instead of integrating directly in a final branch, you generate a
diff and throw that along with the diff's name in to debian/patches. That's
it. It could be totally automated from your current setup without much
work, if that's what you want. This is not making you give up anything,
it's about improving the base standard so everyone can get more information
without learning a zillion different patch systems and vcs's. As a result,
we can focus on improving the code itself instead of the process of
managing the code.

So, in summary, stop trying to act like you're being forced to do something
that's going to hurt you. No one is taking away your toys.

> > This argument assumes that dpkg-source -x will apply that patch stack
> > automatically as well, which has been discussed elsewhere.
> 
>         Currently vapourware, no?

This thread is partially about how to implement this very feature, so
calling it vapor while it's still being planned is unfair.

 - David Nusinow



More information about the vcs-pkg-discuss mailing list