From owner-cvs-usrbin  Mon Dec 30 14:42:54 1996
Return-Path: <owner-cvs-usrbin>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id OAA26079
          for cvs-usrbin-outgoing; Mon, 30 Dec 1996 14:42:54 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA26071;
          Mon, 30 Dec 1996 14:42:45 -0800 (PST)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id OAA10805; Mon, 30 Dec 1996 14:42:17 -0800 (PST)
To: sos@FreeBSD.org
cc: joerg_wunsch@uriah.heep.sax.de, CVS-committers@freefall.freebsd.org,
        peter@spinner.dialix.com, peter@freefall.freebsd.org,
        cvs-all@freefall.freebsd.org, cvs-usrbin@freefall.freebsd.org
Subject: Re: cvs commit: src/usr.bin/vi Makefile 
In-reply-to: Your message of "Mon, 30 Dec 1996 23:18:13 +0100."
             <199612302218.XAA00724@ravenock.cybercity.dk> 
Date: Mon, 30 Dec 1996 14:42:16 -0800
Message-ID: <10780.851985736@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-cvs-usrbin@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> What was wrong with the old ways, base & ports ?? I worked pretty
> well, maybe we should have given it a fancier name or something,
> but it was the right idea...

The right *general* idea, but the number of problems which it leaves
unsolved are numerous.  We ran into the most obvious one the minute we
started writing and incorporating perl utilities into the system, and
perl4 slid on in to solve the dependency problem.  We will keep having
dependency problems and the ports & packages collection will keep
being a non-solution to them for just as long as we keep it fully
decoupled from the source & binary distribution system.

I'm not even sure that keeping it decoupled is such a bad idea, but
you can't have it both ways - either the ports and packages collection
remain ideologically and functionally separate, and things like Perl5
and TCL come into the tree in order to solve our basic tool dependency
issues, or ports and packages becomes part of a more cohesive
load-on-demand system where the line between initially loaded
distributions and packages goes away entirely (same for sources and
"ports") and we stop even worrying about this, since the user will
configure his system in much the same way as the VM system fills the
buffer cache - on demand! :-)

However, the latter is also a lot of work.

						Jordan