This is the mail archive of the
mailing list for the Cygwin project.
Re: Fwd: Subversion packages
- From: David Rothenberger <daveroth at acm dot org>
- To: cygwin at cygwin dot com
- Date: Mon, 18 Nov 2013 10:35:58 -0800
- Subject: Re: Fwd: Subversion packages
- Authentication-results: sourceware.org; auth=none
- References: <CAFMYRRMFGxJhMKNKVgUEs45Lb5dLCf-5vq+Rp5s0H=Eg1yB5kw at mail dot gmail dot com> <CAFMYRRPZWqSJWZVVGDQLLZ55ZOcD_H9q7UgPr4iZyKw9vr2TbQ at mail dot gmail dot com> <52890843 dot 90903 at acm dot org> <CAFMYRRPt+9U_GcrRwQoOPn4OxpqmW44uy4stp-auX+KYg4pr8w at mail dot gmail dot com>
- Reply-to: cygwin at cygwin dot com
Kevin Connor Arpe wrote:
> I was thinking about this type of SVN package setup:
> * 1.6.x (svn_1.6)
> * 1.7.x (svn_1.7)
> * 1.8.x (svn_1.8)
> * svn (latest -- currently svn_1.8)
> I could create statically linked binaries that can live side-by-side,
> e.g., /usr/bin/svn1.6, svn1.7, svn1.8 and plain old "svn" which is the
I'm strongly against statically linking the binaries. It produces
very large binaries and will require recreating the binaries any
time a bug is fixed in any of the many dependent libraries. It also
does not address the API bindings which require DLLs to function,
for example the Perl binding used by git-svn. There is also the
Apache module to consider.
I suppose you could have a system where the versioned svn packages
provide only a statically linked binaries and none of the other
libraries, while the unversioned Subversion packages provide
dynamically linked binaries and all the libraries.
I know of no other Linux distribution that supports multiple
installed versions of Subversion. I don't think it's a good idea.
But if you want to pursue this further, I suggest the following:
* Make sure you can build the subversion packages from the cygport
files for both 32-bit and 64-bit Cygwin.
* Make sure you can build the dependency libraries I currently
support (libapr1, libaprutil1, serf, and scons), again for 32-bit
and 64-bit. Make sure you are willing to adopt them. I might be
persuaded to continue to maintain them, but since I do so solely
for Subversion, I'd rather you took them over as well.
* Produce a cygport file for a statically linked svn_1.6 package.
* Provide a detailed proposal include the cygport file on the
cygwin-apps mailing list.
Prior to all that, though, I suggest you ask the Cygwin maintainers
and other packagers for their thoughts. There may be resistence to
this from the project as a whole. I'm not sure if this list or
cygwin-apps is best for that discussion, though.
David Rothenberger ---- firstname.lastname@example.org
The world really isn't any worse. It's just that the news coverage
is so much better.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple