[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Stop shipping deps tarballs [was Re: Hosting tarballs on ASF infrastructure]

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Fri, 14 May 2010 06:56:58 -0500

On Thu, May 13, 2010 at 11:44 PM, Joe Swatosh <joe.swatosh_at_gmail.com> wrote:

> On Tue, May 11, 2010 at 7:59 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
> > On Mon, Apr 26, 2010 at 11:20 AM, Hyrum K. Wright <
> > hyrum_wright_at_mail.utexas.edu> wrote:
> >
> >>
> >>
> >> On Mon, Apr 26, 2010 at 11:06 AM, Mark Phippard <markphip_at_gmail.com
> >wrote:
> >>
> >>> On Mon, Apr 26, 2010 at 11:44 AM, Hyrum K. Wright
> >>> <hyrum_wright_at_mail.utexas.edu> wrote:
> >>> > This looks like a good location, do you know what needs to happen so
> I
> >>> can
> >>> > get the appropriate privs to upload to the subversion/ directory
> there?
> >>> >
> >>> > Also, I'm planning on just putting the release tarballs, not the deps
> >>> > tarballs. Any reason why we should include the deps tarballs?
> >>>
> >>> I was under the impression we couldn't post it unless we remove Neon
> >>> and maybe other parts.
> >>>
> >>> Personally, I think this is a good opportunity to stop making it.
> >>>
> >>
> >> I would *love* to stop shipping the deps, and would be happy to make
> this
> >> happen as part of the 1.7 release cycle. It would be nice to hear from
> our
> >> users / packages / 3rd-party-clients to find out if they actually use or
> >> care about the deps tarballs before we banish them, however.
> >>
> >
> > As I've gone back and reviewed this thread, it seems that sentiment seems
> to
> > be leaning in favor of dropping the deps tarballs from our distribution.
> > I'm inclined to follow that path, and will make the needed changes to our
> > distribution scripts to remove them. If you have objections, please make
> > them known.
> >
> > (Note: this would only be in preparation for the 1.7 release. 1.6.x will
> > continue to ship with the deps tarballs.)
> >
>
> Hi Hyrum,
>
> As one of the (probably) few (on list) users of the deps tarballs, I
> have no problem with dropping them. If that is the decision however,
> I'd like to suggest that we should be very clear about what versions
> of the dependencies we "recommend" (which is approximately how I
> treated the deps until now), and we should also include links to where
> that version is available (at least at the time that our release
> ships).
>

Thanks for the input. The "canonical" source for the deps versions is the
distribution scripts:
https://svn.apache.org/repos/asf/subversion/branches/1.6.x/tools/dist/construct-rolling-environment.sh

However, I actually use a local copy of that script when rolling deps, and
it is occasionally updated with newer versions when the situations warrants
(such as with the recent zlib releases). Those updates get committed to
trunk, but rarely do they get backported to the branch.

> After a bit of googling, I found all the dependencies in 1.6.11, but
> it wasn't easy in every case.
>
> For the record:
> http://archive.apache.org/dist/apr/
> http://zlib.net/fossils/
> http://serf.googlecode.com/files/
> http://www.webdav.org/neon/history.html
> http://www.sqlite.org/download.html
> (Not in the deps tarball, but a dependency none the less: I've been
> using the prebuilt bdb for windows from the tigris site. I'll
> probably have to figure out how to build it RSN.
>
> http://www.oracle.com/technology/software/products/berkeley-db/db/index.html
> ).
>

Berkeley DB isn't considered a "strict" dependency, since you can build a
fully-functioning Subversion without it. The same could probably be said of
neon and serf, but for historical reasons, we include them.

It sounds like dropping deps is acceptable. I'm going to update the rolling
script on 1.6.x to the appropriate versions, and then start hacking the
trunk distribution scripts to not create the deps tarball.

-Hyrum
Received on 2010-05-14 13:57:29 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.