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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
