X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:reply-to; q=dns; s=default; b=q/0dZG9OeLnvm3WuM3Ond56HPHJsRGf5v
	KfUS2Yugmw+UKOjNEVjZLSGjYoJm1LFwiUHhTRt5+VjrIocXcB2eG9cP2KVDY6lv
	7oxJmmieJbWGQdBKzx/3NtbmTvRNANCERTX7Jgvok8EtNdD7XZXqZkm06fJHvYC0
	4s3OalkbFk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:reply-to; s=default; bh=w6izEmkGBT6nWj0PC6HDshjKM2Q=; b=i00J+70
	CCMmE/CiwWFIDIavukjPuwqt58I1xDk/9S0RwOR01f3HaZ1gs7ETM4rzGnwSPZYL
	I1IDne+qdEASXY978hQacXVRhVx6KrIQTS8uVbZn/n7SHUz1xBixATh4L/jcNVcd
	svWuvazQLqyclndb9x2715D96GuxhV/FFb/Q=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=2.3 required=5.0 tests=BAYES_50,RDNS_NONE,SPF_SOFTFAIL,URIBL_BLOCKED autolearn=no version=3.3.2
X-HELO: qmta08.emeryville.ca.mail.comcast.net
Message-ID: <528A5E0E.7000906@acm.org>
Date: Mon, 18 Nov 2013 10:35:58 -0800
From: David Rothenberger <daveroth AT acm DOT org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Fwd: Subversion packages
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>
In-Reply-To: <CAFMYRRPt+9U_GcrRwQoOPn4OxpqmW44uy4stp-auX+KYg4pr8w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
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
> latest.

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  ----  daveroth AT acm DOT 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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple