From owner-freebsd-current  Tue Mar  5 15:35:05 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id PAA06875
          for current-outgoing; Tue, 5 Mar 1996 15:35:05 -0800 (PST)
Received: from sunrise.cs.berkeley.edu (sunrise.CS.Berkeley.EDU [128.32.38.121])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA06860
          Tue, 5 Mar 1996 15:35:01 -0800 (PST)
Received: (from asami@localhost) by sunrise.cs.berkeley.edu (8.6.12/8.6.12) id PAA08565; Tue, 5 Mar 1996 15:37:01 -0800
Date: Tue, 5 Mar 1996 15:37:01 -0800
Message-Id: <199603052337.PAA08565@sunrise.cs.berkeley.edu>
To: jkh@time.cdrom.com
CC: jkh@freebsd.org, freebsd-current@freebsd.org
In-reply-to: <4808.826057211@time.cdrom.com> (jkh@time.cdrom.com)
Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-current@freebsd.org
Precedence: bulk

 * In fact, I'd no intention of even putting a -current packages
 * collection up for the FTP SNAP (I've never made a practice of doing
 * this up to now, after all), and was doing it only for the CD because a
 * CD has all that space left over..

The -current packages are already up there on wcarchive, you just need
to fix the paths in sysinstall to get them! :)

 * I think that trying to syncronize the SNAPs and the packages
 * collection is a bit insane, actually, and I'd be perfectly happy just
 * to copy the 2.1-RELEASE packages dir onto all of them and make sure
 * that a compat21 distribution gets put together.

Uuh...I don't think that's a very good idea.  The packages-current
subtree is exactly for purposes like this, why don't you just use that
instead?

It's probably in much better shape than 2.1R packages (in terms of
running on a 2.2-* system), and most of the packages are already built
at one time or another after 2.1R came out.  I really can't think of
any reason to use the 2.1R packages for the 2.2 snap....

 * I wouldn't waste the effort, to be honest.  I'm going to be doing this
 * too often for you to ever have a hope of keeping something as huge as
 * the packages collection in sync, so why set a precedent you won't be
 * able to keep?

It's just that the libc change that occurred quite recently.  The
packages-current is quite well-synchronized to the ports-current tree,
as I build the packages as soon as (I can after) I see the commit
messages.

So there really isn't much trouble keeping it in sync.  The huge
rush/freeze thing before the release is mainly due to my insisting
that the packages be tested properly for a while, and for snap users,
packages-current should be much better (later versions, more new
ports, etc.).

 * Believe me, if I thought that a -current version of the packages
 * collection to go along with each SNAP CD was a practical goal, I'd
 * have been talking to you a lot sooner than this!

Well, I think it's a practical goal, and even if we don't rebuild it
right now, it should still work better than the 2.1R packages with
your snap (which will require the old libc anyway).

Convinced? :)

Satoshi