[1823] in athena10
Separate packaging [Re: Athena delete]
daemon@ATHENA.MIT.EDU (Anders Kaseorg)
Mon Mar 23 15:01:32 2009
Date: Mon, 23 Mar 2009 15:00:32 -0400 (EDT)
From: Anders Kaseorg <andersk@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: debathena@mit.edu
In-Reply-To: <29FD6D41-E68F-4170-B174-5E9F1D5C7CCC@mit.edu>
Message-ID: <alpine.DEB.2.00.0903221400470.4457@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Sun, 22 Mar 2009, Jonathan Reed wrote:
> Addressing the general case, I'm not sure how the presence of a debian
> directory or spec file implies that the software is not separable from
> its packaging. I can think of several packages that ship with spec
> files and/or debian directories for easy packaging.
This is not just unnecessary cruft, but is in fact strongly discouraged,
especially for Debian, as I pointed out here:
<http://diswww.mit.edu/menelaus/athena10/67>
When multiple packaging systems are involved, or worse, multiple packaging
systems maintained by different people, there is the additional problem
that the overhead of keeping them all in sync becomes a severe impediment
to fast development.
> If the debian directories were not in the source tree, where would they
> be and what would the build process look like? If they live elsewhere,
> could RPM spec files and, say, OS X package metadata live there too?
(Walking boldly into the ponyverse here.)
We didn’t have a good solution to this problem until the rise of version
control systems with good merging support. (Subversion 1.5 sorta counts,
but DVCSs like Git are much better.) When you have that, the solution is
to keep each packaging system in its own branch.
The VCS keeps track of which upstream version is the most recent ancestor
of which packaging branch, so it is not critical to keep them all in sync
at the same time. This kind of structure is natural to maintain,
especially with tools like git-buildpackage (which lets you automatically
generate debian/changelog from commit messages, among other things).
For example, my nss_nonlocal repository at
git://andersk.mit.edu/nss_nonlocal.git looks like this in the gitk
repository visualizer:
<http://web.mit.edu/andersk/Public/nss_nonlocal-gitk.png>
We talked briefly about using Git near the beginning of the project:
<http://diswww.mit.edu/menelaus/athena10/9>
At that point, I had not yet tried maintaining a Debian package using Git.
Now I maintain a few, and given that experience I would have advocated
much more strongly for Git over Subversion.
Anders
