As we're plodding on with backports on IRC, the question of whether we
should stop packaging dependencies in our release tarballs came up
again, and it seems there is a consensus that we want to stop shipping
deps in our release tarballs.
We had this debate during the 1.3.x release process, and it didn't
work out, because we tried to ship two svn tarballs, one with no deps
and one with the deps. This doubled the number of files to verify,
too heavy.
So, for 1.4, we would like to try going with another option that was
proposed: ship two tarballs (plus bz2 and win32 variants, of course):
- subversion-1.4.0.tar.gz : the Subversion source code, no deps.
- subversion-deps-1.4.0.tar.gz : the dependency package, which
decompresses as an overlay to the previous tarball, adding
APR/Neon/etc. to the plain svn source tree.
This is relatively simple from the point of view of distribution, as
the dist.sh can be adapted to splice out the deps into a separate
package.
So, first of all: If anyone has a *very* good reason, beyond "I don't
like it", for not wanting this two tarballs regime, let them speak up
now, and propose another solution that let us not bundle deps with our
releases.
The second question is more os a bikesheddy question, but that needs
an answer nonetheless: what should we put in the deps tarball? Neon,
Serf, zlib, BDB, APR ? Which versions of these?
I admit I don't really care here, as I will likely never use the deps
tarball. So, what do people who will be using it want in there?
Which libs can be considered widespread enough to omit?
If the thread spirals out of control by the time I roll 1.4RC2, I'll
go for a status quo, and package in the deps tarball the deps we would
have packaged with the svn source (apr and friends 0.9 and neon).
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 18:03:35 2006