DragonFly BSD
DragonFly kernel List (threaded) for 2003-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: new sysinstall


From: Steve Mynott <steve@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 01 Sep 2003 21:26:49 +0100

G065363@xxxxxxxxxxxxxxxxxxxx> <20030901144956.GA8023@xxxxxxxxxxxxxxxxx>
In-Reply-To: <20030901144956.GA8023@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 45
Message-ID: <3f53ab8b$0$272$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 62.3.198.42
X-Trace: 1062448012 crater_reader.dragonflybsd.org 272 62.3.198.42
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:827

Joerg Sonnenberger wrote:

> One thing really worth mentioning: Using site.py it is no problem to
> have /usr/lib/python2.3 for the base library and /usr/local/lib/python2.3
> for local additions.

Brainstorming here about paths and possible simple packaging mechanisms 
using the UNIX file system itself...

I have been in the habit of running multiple installations of different 
versions of scripting languages and have found the

--prefix=/usr/local/whatever-x.x.x

switch to the GNU-like configure (found in PHP4 and Python for example 
and probably 95% of software in ports) very handy since then all files 
from 'make install' go under ONE single directory which is cleaner and 
easy to manage IHMO.

I was just pondering whether you could extend this principle to every 
file in the system by having it associated with a package name foo by 
being under the directory hierarchy of a particular directory name foo 
(with an associated version number).

eg.
/usr/local/php-4.3.3/bin/php belongs to package "php-4.3.3"

One drawback would be ending up with

/bin-0.99/sh belongs to package "bin-0.99"

although I suppose you could link to create a /bin (which could be 
useful with rolling back binary system upgrades) or "tag" the directory 
with a version number in a less obvious way (any UFS hacks possible?) 
since it is kind of ugly.

A related issue is how ports usually now puts stuff in the default 
"configure" location under /usr/local.

This tends to clash with software "configure"d outside of ports, which 
is probably why NetBSD use /usr/pkg as a base for their ports (or 
whatever they call it :) ) installation.

-- Steve




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]