On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote:
[...]
> > Why do you call dpatch 'obfuscated' ?
[...]
> Compared to simply making the source changes directly, it's obfuscated.
Agreed.
> It's also obfuscated for users who can no longer use 'dpkg-source -x'
> (as documented since the dawn of time) to see the source code from which
> programs are built; instead, they have to hunt through a maze of twisty
> makefiles in order to work out the correct debian/rules invocation to
> produce the patched source, which is different for almost every patch
> system used in Debian and is often poorly documented.
dpatch is actually documented quite well. (The packaged dbs also
features usable documentation.) Hell starts with the homegrown
patch-systems or cdbs.
> I recommend using a good revision control system instead, which offers
> similar benefits to developers while leaving things clear for users.
I disagree that this is so clear-cut. The still most popular system
CVS simply does not offer this functionality. e.g. you have two
distinct patchsets: patchset A fixing issue A touching files 1, 2,
and 3 and patchset B fixing issue B touching files 2, 3 and 4.
CVS simply does not offer the possibility to keep these patchsets
separate (except for checking in diff-files.) over several generations
of a file.
I doubt svn favours a lot better in this respect (otherwise why would
xfree-packaging still use a dpatch-like system?) Bitkeeper can do it,
and I guess arch, too.
If you are thinking "use separate .diff files in your repository but
upload a plain diff.gz with everything mangled together" I disagree.
I'd rather have slightly more complicated but usable sourcepackages in
the archive. (Think of maintainer goes MIA or NMU.)
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
