Re: How to cope with patches sanely (Was: State of the project - input needed)
On Fri, Jan 25, 2008 at 08:26:04AM +0100, Andreas Tille wrote:
>> I think:
>>
>> http://kitenet.net/~joey/blog/entry/a_problem_with_tools/
>>
>> is a big one that deserves attention. It's been a low-level grumble for
>> quite some time in various places, but it's getting louder. It's a
>> difficult problem in that it's a balance between tools that make DDs more
>> productive and the ease of treating Debian packages in a uniform manner.
>
> I completely agree that this topic deservers attention and thus I
> would like to start a discussion here. IMHO there is a need for putting
> patches against upstream source into a defeult place. The rationale
> behind this is that if you are using VCS for your packaging to enable
> effective group maintainance it makes no sense to store a complete
> tarball but just the patches. For instance in the Debian-Med project
>
> http://svn.debian.org/wsvn/debian-med/trunk/packages/
>
> we agreed to store only the debian directory into SVN and have a
> get-orig-source target in the debian/rules file. To store the patches
> in the debian directory and apply them later dpatch and quilt are
> widely used tools and I don't know a better solution.
>
> What would you suggest to enhance the situation?
What bothers me about Joey's blog entry, and other similar proposals, is
that it ignores a major reason for having external patch systems in the
first place. Many of us have to carry long-lived patches to very
complicated software. I'm personally thinking of the X server, but there
are bound to be other examples. Additionally, we often have to carry
several of these throughout the lifetime of the package. We also have to
carry patches that aren't yet suitable for upstream, but may eventually
become so. Finally, we have to carry patches backported from upstream HEAD.
The idea proposed by many people, to keep the patches merged in your
debian-specific branch, only really improves lives in the last case, when
those patches are going to be merged in for the future anyhow. In any case
where you have a patch that isn't going to go upstream for a long while, if
ever, keeping these patches merged becomes painful. If the patches are
large, then you'll forget most all of the details which makes merging
painful. Additionally, it becomes quite difficult to see a large patch that
touches many files in the whole. A great deal of archaelology becomes
necessary to cope with that. If the patch becomes suitable to go upstream
after some time, it also becomes hard to extract that patch to be sent
later.
An alternate idea I keep seeing is feature branches. I have absolutely no
idea why these are considered preferable to most people. In the case of the
X server we regularly carry around 30 patches on our stack. If we were to
put each of these on its own unique feature branch, merging them becomes an
exercise in pain. Sure, we could implement our own custom scripts and have
very strict naming policies, but then you've re-invented the wheel and
congratulations, you have yet another custom piece of crap software that
you have to maintain on top of the already complicated one you actually
care about. Additionally, you have a lot more branches getting in the way
when you're trying to figure out which one you're looking for.
External patch systems are not ideal by any means, but they do clearly
address these issues as well as I could ask for. It's trivial to update the
patches, just go one by one through them. You can trivially see the patch
in full, which makes it quite easy to deal with. Patches, once ready, can
be easily sent upstream for later inclusion. Patches can be commented in
their headers, which allows an easy single place to collect information
rather than having to scour through your history.
None of these benefits has been acknowledged or even addressed by people
who are against these systems. These are huge wins for many of us. While
I'd love to see something like stgit or guilt become really useful to us so
we could keep our stuff cleanly in git, to date there isn't a great
solution.
As for which patch system to choose, as far as I'm concerned if you're
going to use one the *only* option is quilt, because quilt is the only
system that scales all the way up to the most complicated packages. When I
was working on the Xorg monolith (carrying around 100 patches, many of them
very complicated) moving from dbs to quilt cut the time to deal with those
patches from 2 months to 2 weeks. dpatch has the same problems as dbs,
which really leaves only quilt as a workable option for all packages.
If we can't figure out a good and clean way to keep a large stack of
long-lived patches in the vcs then I firmly believe we should standardize
on quilt.
- David Nusinow
Reply to: