On Mon, May 02, 2005 at 12:38:09AM +0200, Michael Banck wrote: > On Sat, Apr 30, 2005 at 04:03:42PM +1000, Matthew Palmer wrote: > > Nah, you can range all over the place and change things. It all gets > > recorded in the .diff.gz file in the end. > > However, best practise is to include your changes as patches in > debian/pathces and use a patch-system like dpatch, quilt or cdbs' > simple-patchsys. The voice of bitter experience: That's not best practice, that's crack. Separately storing patches in the diff.gz is something that looks like a nice idea, until you actually have to do it for a while against a fast-moving upstream. Problems (with the dpatch case at least, although some of these problems definitely apply to other systems as well) include (but are not limited to): * There's sweet FA useful information in each patch regarding change history. Even interdiff isn't useful between upstream versions because of changes in the patch base. Before you say "but you can add that into the patch header", I'll say "use a real f**king revision control system then". * Retargeting your patches for new upstream versions is a right royal pain in the arse. As an added bonus, patches that do apply cleanly but with fuzz aren't renumbered, so sooner or later you're going to get fuzz failure even if nothing else has actually changed. * A dpkg-source -x unpacked package is no longer what you build from, so the naive QA activities no longer work. There's already three different ways to apply patches after the package is unpacked, and I have no doubt that people will dream up more new ones as time goes on. Note that this problem also exists with the mere existence of all these different build systems, but it is less of a problem because it normally only affects QA people who need to fiddle with Debian build bits, whereas the patching problems range over the entire codebase. * Some of the patch-applying build systems have the unpleasant habit of summarily removing the bits you've been hacking on every time you rebuild the package. This particularly annoys QA people who do not have the necessary build-system fu to know this, when your test build quietly eats the changes you're trying to test. And all of these problems can be averted by doing the right thing, and using a real revision control system and then shipping a regular ol' "everyone knows how this works" debhelper-based .diff.gz. - Matt
Attachment:
signature.asc
Description: Digital signature