P.S. [mirian@cosmic.com: Re: A Linux Elbows - flavors]
P.S. I forgot to include the reasoning behind this "cvs/rsync-like"
diff format. [And, yeah, we'd need a patch tool, as well, which
can use these diffs.]
Thanks,
--
Raul
----- Forwarded message from Mirian Crzig Lennox <mirian@cosmic.com> -----
From: mirian@cosmic.com (Mirian Crzig Lennox)
Subject: Re: A Linux Elbows - flavors
Date: 22 Dec 2000 15:42:57 -0500
Organization: Cosmic Computing Corporation of Alpha Centauri
I wrote:
>In general, debian packages are developed "upstream". If the
>package is under going active development, it's probably already
>in cvs, and ideally the debian changes are being merged into
>the upstream system.
Yeah, that's a really nice theory. The problem is, most of the time it
doesn't happen, and it's *really irresponsible* of you (and the Debian
bureaucracy as a whole) to cavalierly pretend that a problem doesn't
exist when the "ideal" case doesn't happen.
As an example of what I'm talking about, here's three packages I've had
to wrestle with recently (all from potato):
Size of debian Number of source
patch file files affected
------------------- ----------------
gcc-2.95.2-13 1.36M (47103 lines) 408
esound-0.2.17-7 130K (4932 lines) 58
exim-3.12-10 209K (5484 lines) 67
Huge monolithic patch files like this are just fucking useless, and
the debian/changelog is no help because it doesn't cross reference
the patches incrementally, as cvs does.
And the above is pretty much the norm for debian source packages.
They're an outside developer's nightmare.
Please, please, please take a look at the FreeBSD ports collection,
the anoncvs server and the cvsweb interface. THIS is how to do an open
source package collection without making life a living hell for outside
developers.
--Mirian
----- End forwarded message -----
Reply to: