Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Jul 2002 00:39:25 -0700
From:      Wes Peters <wes@softweyr.com>
To:        Mark Valentine <mark@thuvia.demon.co.uk>
Cc:        Terry Lambert <tlambert2@mindspring.com>, Jordan K Hubbard <jkh@queasyweasel.com>, Dan Nelson <dnelson@allantgroup.com>, Archie Cobbs <archie@dellroad.org>, Dan Moschuk <dan@freebsd.org>, Dag-Erling Smorgrav <des@ofug.org>, arch@freebsd.org
Subject:   Re: Package system flaws?
Message-ID:  <3D2E87AD.76DC449D@softweyr.com>
References:  <200207120055.g6C0tbpQ084565@dotar.thuvia.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Mark Valentine wrote:
> 
> > From: wes@softweyr.com (Wes Peters)
> > Date: Thu 11 Jul, 2002
> > Subject: Re: Package system flaws?
> 
> > On problem in particular comes from changing the PREFIX of a
> > package.  You can easily do this in the package tools, but how do you
> > change the BINARIES to realize they've been installed under another
> > PREFIX?
> 
> How about providing a packaging API call (and utility) for the packages
> to grab their install root from a record in /var/db/pkg?  Something
> like pkg_getroot(3) and pkg_config(1).

I was thinking we could replace a lot of the mish-mash in /var/db/pkg
with a munged up version of the metadata file that includes all the 
real file locations, translations for various meta directory names,
etc.  Providing a simply library function to translate PREFIX for 
"my package" or a named package would be ever so sensible.

> There probably isn't much less intrusive way to make a package's root
> configurable at install time.

It's a good idea, if we can just get the application developers to use it.
Actually you might be able to do it by forcing autoconf to code in a
meta-name for each the directory prefixes and linking against an overridden
version of open(2) that properly translates the meta-name.  But that's
icky.  And the next thing you know, somebody's gonna want that function
to allow the meta-name to be expanded to a path, etc. etc.  Augh!

> If you didn't want the package to have to look in /var/db/pkg, have
> the package binaries hold a maximum-length padded string variable (marked
> similarly to what(1) strings), and provide a tool to edit the binary (and
> scripts) at install time.

Similar to the above, substituting scary editing of binaries for 
scary library linking.  ;^)

> I think environment variables are too fragile for this purpose.
> 
> > You could almost do this on UNIX now, by putting such settings into
> > init's environment, if you could get the application developers to
> > write their code (especially libraries) appropriately.
> 
> This doesn't sound like it would be easy to allow different packages to
> be installed with different roots.

You're right.  VMS has a system table, a per-group table, and a per-user
table to allow overrides.  They teeter between being neat features and
be overkill.

-- 
            "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                         Softweyr LLC
wes@softweyr.com                                           http://softweyr.com/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2E87AD.76DC449D>