dpatch/dbs/etc/etc/etc/etc considered harmful

Followup to last post, transcript of #debian-boot.

<Caesar> joeyh: Edumacate me on the evils of dpatch
* Kamion drops all patch systems down a deep well, there to stay rotting forever with any luck
<Caesar> How come?
<Caesar> I honestly though dpatch was pretty neat, but I'm obviously not seeing part of the picture
<Kamion> horrible obfuscation when you're just trying to unpack the damn source package
<Kamion> $ debian/rules patch
<Kamion> $ debian/rules patched-source
<Kamion> $ debian/rules apply-patches
<Kamion> $ debian/rules unpack
<Kamion> $ debian/rules extract
<Kamion> $ debian/rules source.make
<vorlon> Caesar: take a look at a dpatch package using debdiff sometime
<Kamion> $ make -f debian/sys-build.mk source.make
<Kamion> # aaaaaaaaaaaaaaargh
<vorlon> Kamion: where's debian/rules setup? :)
<Kamion> vorlon: knew I'd missed at least one
<Kamion> all the above are variants I've seen, with the possible exception that I might have misspelled the last one
<Caesar> So you anti-dpatchers prefer to see all the changes just rolled up in the diff.gz?
<Kamion> yep
<Kamion> use a revision control system
<joeyh> huh, my techniques is debian/rules build && ctrl-c :-P
<Caesar> Fair enough.
<Kamion> joeyh: that's my last resort
<Caesar> I need to get onto this whole revision control system bandwagon...
<joeyh> but that's only the fun of unpacking, you then have the fun of trying to patch a broken patch to put in a securityu fix or so
<joeyh> so then you get to edit patches or patch patches or some such insanity
<Kamion> bonus points for putting directions to your revision control system into debian/README.build or something so people can inspect it
<Kamion> pitti used to put patches in debian/patches/ that patched files in the debian/ directory, until we re-educated him with a stick
<vorlon> haha
<Kamion> if there were just one patch system, then it would be OK to learn its toolset for editing patches (there's usually something that lets you work on a patched tree rather than on the patch file)
<Kamion> but no, there are about seventeen patch systems with lots of people's pet variations
<Caesar> That's what I was liking about dpatch
<Caesar> It had a semi-decent toolset
<Kamion> it's all very well for people using dpatch for all their packages, but for people who have to edit packages all over the place, they don't have the luxury of just one system
* Caesar feels dirty for having made numerous QA uploads of orphaned
* packages and added dpatch support
<joeyh> well, that's basically a "please don't adopt this" upload
<joeyh> or a "here, waste an hour if you do adopt this" at least
<Caesar> Cringe
<Caesar> Here I was thinking it made the patch more atomic...
<Caesar> (which was my reasoning behind using dpatch)
<Caesar> i.e. made it easy to throw away individual patches if they weren't required any more
<Kamion> the approach used by the perl package is somewhat better
* Caesar goes and looks
<Kamion> it stores patches applied to the source package in debian/patches/, but ships the .diff.gz with them all applied
<Kamion> you get duplication, but you also get to unpack the source with the standard tools and see what gets built, and in a worst case as an NMUer you can just change the source tree directly and let the maintainer sort it out later
<Caesar> I guess NMUing is a more of a big deal in Ubuntu because you don't have specific maintainers for specific packages
<Kamion> well, (a) that's sort of sometimes true, (b) our beloved universe maintainers all seem to be dpatch/similar fanatics so ...
<Kamion> some battles I have given up fighting
<joeyh> pity that arch thing didn't work out

hth