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
signature.asc
Description: Digital signature
