Subject: Re: Default for PKG_SYSCONFBASE
To: Joerg Sonnenberger <joerg@britannica.bec.de>
From: Julio M. Merino Vidal <jmmv84@gmail.com>
List: tech-pkg
Date: 06/09/2007 21:21:09
On 09/06/2007, at 20:55, Joerg Sonnenberger wrote:

> On Sun, Jun 03, 2007 at 05:20:28PM +0200, Julio M. Merino Vidal wrote:
>> - /etc is the place that is supposed to have the configuration files.
>> - Configuration files are usually per-host, but this is not easy to
>>   achieve if /usr/pkg is network-shared.
>
> Mount a local file-system over it.

No thanks.

> I should add that changing the default means a lot more work for bulk
> builds. Keeping the set of writeable locations as small as possible  
> is a
> crucial requirement. /etc/pkg is yet another location. This also plays
> somewhat havoc with the original idea of self-contained pkgsrc.

What is "a lot more work"?

Do we really want a self-contained pkgsrc or one that integrates well  
with the system (if built as root)?  If the former, please let's make  
*everything* self contained and deal with the problems that arise  
(that goes for VARBASE).  If the later... things can be much better  
for the desktop user^W^Wsystem administrator.

And if syspkgs ever materialize, I'd assume that we would like the  
latter.

>> - VARBASE is also a configurable setting and _does not_ default to
>>   PREFIX/var.  It "correctly" points to /var.
>
> In contrast to etc I expect VARBASE to be volatile. My own  
> configuration
> here has a read-only / and read-write /var.

Except that many things in VARBASE are _not_ volatile.  And the  
clearest example is PKG_DBDIR (or, for that matter, /var/chroot in  
NetBSD).

> I should also add that if you want to mount /usr read-only, you can
> create /usr/pkg/etc as symlink without breaking anything.

Yeah well...  but that does not change the fact that the default we  
now have is bogus.  Many of the defaults we now have are the way they  
are because of historical reasons, including those where nobody cared  
to consider the different possibilities and the implications of  
setting that default value.

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>