DragonFly kernel List (threaded) for 2003-09
Re: new sysinstall
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1062448012 crater_reader.dragonflybsd.org 272 220.127.116.11
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
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).
/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.