From owner-freebsd-ports Wed Aug 28 10:48:36 1996 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16470 for ports-outgoing; Wed, 28 Aug 1996 10:48:36 -0700 (PDT) Received: from xenon.chromatic.com (xenon.chromatic.com [199.5.224.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA16465 for ; Wed, 28 Aug 1996 10:48:34 -0700 (PDT) Received: from server1.chromatic.com (server1.chromatic.com [199.5.224.120]) by xenon.chromatic.com (8.7.5/8.7.3) with ESMTP id KAA25245; Wed, 28 Aug 1996 10:48:02 -0700 (PDT) Received: from localhost (hua@localhost) by server1.chromatic.com (8.7.5/8.7.3) with SMTP id KAA01233; Wed, 28 Aug 1996 10:47:48 -0700 (PDT) Message-Id: <199608281747.KAA01233@server1.chromatic.com> X-Authentication-Warning: server1.chromatic.com: hua owned process doing -bs X-Authentication-Warning: server1.chromatic.com: Host hua@localhost didn't use HELO protocol X-Mailer: exmh version 1.6.8 8/21/96 To: kientzle@netcom.com cc: hua@chromatic.com, freebsd-ports@freebsd.org Subject: Re: Linux async vs. FreeBSD sync (fwd) In-reply-to: Your message of "Tue, 27 Aug 1996 14:59:23 PDT." <199608272159.OAA22646@netcom2.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Aug 1996 10:47:47 -0700 From: Ernest Hua Sender: owner-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been using a private scheme doing precisely the same thing (each application version to its own directory). This has the enormous advantage of being able to upgrade/downgrade a single application in a snap. My own scheme is a bit klunky, and I would prefer some more fully-automated methods. The issue I ran into is: Transparent installation. Many programs are not quite as automatically configurable as GNU and company. Therefore, manual patching of path names (installation and execution) are necessary. Ideally, every program to be installed will truly believe they are being installed in /usr/local, but will actually be copied somewhere else, but with proper symbolic links to make it look just like it was in /usr/local. A full database of files installed (per application version) would be built (automatically, probably by faking out programs such as cp and install) to allow arbitrary removal/upgrade/downgrade of any version of any application. Ern > An alternative package system that I've been using successfully for several > months now is to install _every_ application in it's own private directory, > and then populate /usr/local/{lib,bin,include,man} with appropriate > symlinks. For example, I have "ispell" installed in /usr/local/app/ispell > as follows: > > /usr/local/app/ispell/bin - public executables > /usr/local/app/ispell/lib - public lib file > /usr/local/app/ispell/man/man? - Man pages > > I've then cobbled a quick Perl script that destroys and then > re-builds the following directories: > > /usr/local/man/man? - links to /usr/local/app/*/man/man?/* > /usr/local/lib - links to /usr/local/app/*/lib/* > /usr/local/include - links to /usr/local/app/*/include/* > /usr/local/links/bin - links to /usr/local/app/*/bin/* > > (I chose /usr/local/links/bin rather than /usr/local/bin to avoid > some transition headaches.) > > The big advantage of this scheme over the current FreeBSD package > scheme is that it's very easy to add a new port to this system, > since you don't have to track down every file and enter it into > some database. Similarly, removing packages is equally simple: just > delete the package directory and rebuild the link directories. > > Currently, this doesn't handle package dependencies, and has some other > weaknesses, but I think it has serious advantages over the current system. > In particular, it easily handles new programs and ports as well as > existing packages.