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

Re: Dropping dependencies in tarballs

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2006-04-08 04:51:59 CEST

David Anderson wrote:
> * Nicol?s Lichtmaier <nick@reloco.com.ar> [2006-04-07 18:09:30]:
>> Why not, instead of "base" and "full", doing this:
>>
>> subversion-1.4.0.tar.gz - Just Subversion
>> subversion-1.4.0-deps.tar.gz - Subversion dependencies.
>
> A very potent idea indeed, thanks for suggesting it!

Yes...

[...]

> And finally, as a tangential aside, it would make distributing an APR
> 1.x ready package much easier, if we want to: just provide two
> dependency bundles, one with APR 0.9 for backward compatibility, and
> one with APR 1.x for those who want a full APR 1.x ready dependency
> suite. And as far as blessing goes, there is still only one
> subversion source package to test, the basic one with no bundled deps.

The only question I have here is how does one say a Subversion tarball is
blessed unless there was some set of versions of dependencies use as part
of the blessing. Without including those you could have developers that
have some mix that is "unnatural" on their systems and thus the code
could end up depending on those features.

Yes, this is true for other libraries (glibc, zlib, etc) but they have
been much more stable in API (they are also much older)

I worry about the fact that APR and NEON tend to have major incompatibilities
between versions, even minor version changes (especially in NEON)

Thus, a split archive (deps and the core source) may make some downloading
smaller (since a fresh rolling of the Subversion code would normally not
change the deps versions) but the testing would still need to be done with
the deps in order to bless a specific combination. Without that, the
blessing process becomes less useful as the combinations needed to reproduce
the various developers blessed version gets unmanageable.

> Thoughts? The dist script can be adapted to perform all of this and
> more, so it's really down to what we feel is right. I'm:
>
> - +1 on shipping a slim tarball and a separate "deps only" tarball
> - +0 on keeping the status quo (and introducing serf for 1.4), and
> - -0 on providing two source code tarballs, with and without deps.

I think that is reasonable, albeit I would be -1 on the two source code
tarballs. The split tarballs works but we need to define the blessing
process relatively strictly such that there is some actual value to the
signatures beyond "some combination works on my machine."

-- 
Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 8 04:53:25 2006

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.