On Thu, 13 Apr 2006, Matt England wrote:
> (I debated about whether or not to post to -users or -dev. My apologies if
> I made the wrong choice.)
>
> Summary:
>
> I want my C++ based project--which happens to be Subversion-controlled--to
> automatically create (via its build process) binary package files, eg,
> .rpm, .deb, .pkg, etc files (and I'm not talking about just src rpms--I
> mean the "binary" rpms).
>
> But before I do, I'm wondering: Why does Subversion not do this? Should I
> take heed from this and not do it for my project (which is on the verge of
> being open sourced and distributed to the public)?
>
>
> Details:
>
> I don't see any rules to automatically make an rpm in:
>
> http://svn.collab.net/repos/svn/trunk/Makefile.in
>
> ...although I do see the package specs in here:
>
> http://svn.collab.net/repos/svn/trunk/packages/rpm/rhel-4/subversion.spec
>
> And of course rpm's are available, but apparently by other people other
> then the "official" Subversion distribution.
>
> Is this a compatibility/CYA move on Subversion's part? eg, is the project
> worried about someone building an improper rpm, distributing it around, and
> making the Subversion project look bad? (Among other things, binary
> compatibility is a tricky issue.)
>
> What reasons would I want to do to not provide a 'make rpm' or 'make deb'
> or 'make pkg' ability from my project?
Hypothesis: It's a question of dependencies, ownership, and
responsibility. Anything in Subverion's build system (and thus,
Makefile) is considered to be "maintained" by Subversion's full
committers, while maintenance of the various native (and often
platform-specific) packaging mechanisms is more often handled by
individuals who focus on that particular aspect.
As a release of Subversion doesn't depend on the packaging (we ship
source tarballs which can be built on numerous platforms), there's no
reason to introduce yet another set of dependencies into Subversion
for something over which the full committer's accept no (official)
ownership. We leave this part of the process to be handled by
downstream packagers, generally reducing the workload for our mostly
volunteer group. (Though don't get me wrong, the Subversion project
wants and attempt to help out with native packages on as many
platforms as possible.)
My employer's (CollabNet's) build system, on the other hand, does
produce native packages for several platforms. Engineers at CollabNet
take responsiblity for this because it *is* one of our deliverables.
Suggestion: Decide whether you want to be responsible for both your
project's source and its packaging.
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Thu Apr 13 22:17:53 2006