[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: errors building a .deb

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

* 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

Reply to: