For the record, I've gone ahead and removed the deps tarball creation from
our rolling script. As of r945390, dist.sh won't create any dist tarballs,
but there is a new get-deps.sh script to help folks fetch the right deps
from a Subversion distribution.
I've rerun my nightly script with the new dist scripts:
Starting with the 1.7.x pre-releases, we'll use this tarball creation
On Fri, May 14, 2010 at 6:56 AM, Hyrum K. Wright <
> 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
>> >>> 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
>> >>> can
>> >>> > get the appropriate privs to upload to the subversion/ directory
>> >>> >
>> >>> > Also, I'm planning on just putting the release tarballs, not the
>> >>> > 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
>> >> happen as part of the 1.7 release cycle. It would be nice to hear from
>> >> users / packages / 3rd-party-clients to find out if they actually use
>> >> 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
>> > distribution scripts to remove them. If you have objections, please
>> > them known.
>> > (Note: this would only be in preparation for the 1.7 release. 1.6.x
>> > 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
> Thanks for the input. The "canonical" source for the deps versions is the
> distribution scripts:
> 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:
>> (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.
> 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.
Received on 2010-05-17 23:44:13 CEST