Hi! On Sat, 2013-05-25 at 09:05:11 +0200, Wouter Verhelst wrote: > Package: dpkg-dev > Version: 1.16.10 > Severity: wishlist
> Before the 3.0 formats came out, there were several patch system > thingies that used similar concepts of having a debian/patches directory > in which individual patches were stored. > > I never touched the things, because the packages I maintain are all > fairly trivial (from a packaging POV, at least), and I just never saw > the need for the added complexity of having to maintain patches in > individual files and having to do all kinds of extra things before I can > properly build a package. > > For this reason, I've never switched to the 3.0 (quilt) format, because > it introduces the same kind of unnecessary complexity. Recently, > however, I learned about the single-debian-patch option, and went ahead > and tried it out on one of my packages. As I wrote in my blog, > however[1], I then found that there are still more things that > dpkg-source decides to do differently from the 1.0 formats. Well, the difference with previous patch systems, is that you should be able to drop a patch in the directory and it will be applied for you, and there's no need to setup infrastructure in debian/rules either. Also most of those other things do have a rationale. :) > I don't buy the argument that splitting off patches into separate files > makes it easier for me to communicate with upstream. I store all my > upstream code and debian packaging data in a git repository; this allows > me to retain the same amount of detail on whatever patches I apply to my > packages (so I can just run "git diff debian..master $(ls | grep -v > debian)" to find still-relevant patches), but has the benefit of > providing more history on a patch (e.g., if a patch changes over the > years, you can see that in a VCS but not in a simple file). I don't agree it's the same amount of detail, it's different details, and IMO less useful. Having the patches split-out is the equivalent of continuously rebasing them whenever there's new upstream releases, so the patches are always clean and usable, they are also logically split, so if upstream or a sidestream (say something not Debian-based), was interested in cherry-picking just some patches then they can see what's useful independently, instead of having to manually split them after the fact (if that'd be feasible at all). Also the history for a patch should be visible through «git log debian/patches/foo.patch» anyway. Keeping the patches in git, will lose that information, and the logical patches might start to decay, with continous git merges, and subsequent fixes to adapt to latest upstreams. This is the equivalent of a code-drop when it comes to packaging. > I do however buy the argument that having a patch system makes it easier > for downstreams to change my packages (they just need to add a file to > debian/patches and be done with it). So I do want to change. I just > don't want to change my workflow. Not one bit. > > Please document how to make dpkg-source behave exactly the same way for > a 3.0 (quilt) package as it does for 1.0 non-native packages, so that > those of us who actually like the 1.0 workflow don't have to go search > for the right options to use by trial and error. I can certainly do that, but probably discouraging or warning on the consequences of its usage, as IMO it's not a good practice. > [1] http://grep.be/blog/en/computer/debian/3.0_source_formats Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
