Re: compile-time configuration, etc.

Paul Jarc (Mon, Apr 21, 2003 at 01:14:45PM -0400):
> Stefan Karrmann <[email protected]> wrote:
> > If package foo should not change data in compile-conf then even the
> > defaults in ./conf-compile must NOT belong to the tar-ball. The defaults
> > may reside in ./package/defaults.
> 
> No.  The only difference between compile-time configuration files and
> files in src/ is that configuration files are intended to be edited by
> the user.  The only reason for separating them is for the user's
> convenience: we can easily see all the configuration parameters
> without hunting through all the source files; we can compare the
> configurations for two different versions of a package with diff -r,
> etc.  But as far as the package's build scripts are concerned, all
> these files should be treated as read-only; destroying the record of
> what the user asked for is not good.  You can still do everything you
> need to do in the build scripts without changing these files.  Why do
> you think you need to change them?

If the configuration files are part of the tar ball and if I repeatly
run 'cd /package && tar xpf foo.tar' the configuration files are
overwritten. If the user has edited these files his changes will be
lost. Thus, you need the default files and a location where the user
can put his preferences.

> > They should reside below ./package or in ./conf-compile.
> 
> I don't think package/ would be a good place for them.  Files in
> package/ are not intended to be edited by the user.

The defaults can be in ./package or ./src and the location for
user preferences can be ./conf-compile (or ./preconf).

> > Below ./compile there may be symlinks to these files.
> 
> Indeed, compile/ can contain anything at all.  But I don't see how
> such symlinks would be useful.  You already know how to access the
> files by their original path, so adding another name seems gratuitous.

If you want to use the directory '..' think of symlinks. The inode of ..
is not aware of symlinks. Thus, you may use the wrong directory. The
only portable way is avoiding .. by using absolute names, sub
directories or firmlinks if you work with Hurd.

Sincerly,
-- 
Stefan