compile-time configuration, etc. (was: registration request)

Stefan Karrmann <[email protected]> wrote:
> Paul Jarc (Mon, Apr 14, 2003 at 01:48:17PM -0400):
>> You have no package/install script.  (I know, I'm guilty of this too
>> in my latest versions.  The new mkmed fixes this and is almost ready,
>> if you're interested in using it.)
>>
>> You have no package/sharing file.  (mkmed could generate one for you.)
>
> Are these required for /package?

What does "required" mean in this context?  They're described on Dan's
web pages, anyway.  I don't know of any code that exists yet that will
break because those files are absent.  But the purpose of describing
them on the web pages is to allow such code to be written in the
future.

If package/sharing is missing, it can probably be considered
equivalent to an empty file (although the web page does not say that
explicitly); having an empty file is equivalent to specifying that all
files are only "host"-sharable.  So this may be wasteful of space, but
is not really harmful.

> Where should the commands copied or symlinked to?

<URL:http://cr.yp.to/slashpackage/manamgement.html>:
# Adding programs to the commands-available-to-users list means
# creating symbolic links in a central directory, /command, as well as
# in /usr/local/bin for compatibility.

> Later runs of 'sh package/compile' only relies on information in
> its own directory tree. (Well, this is my plan - now gcc etc. are
> still needed to be in the PATH.)

What problem is being solved here?  If someone wants to use a
different "cat", a solution is already available: they can set PATH
appropriately.  If necessary, they can create a new directory
containing symlinks to particular commands, and put that directory
first in PATH.  But in the *vast* majority of cases, PATH will already
be correct; the user should not be forced to do extra work in the
common case.

>> My packages currently put compile-time configuration files in
>> preconf/.  It would nice to have consensus here.  What do people think
>> the name should be?
>
> preconf/. is a pretty short name, but 'preconf' does not say that its
> contents must be provided before _compilation_.

True.  I'm willing to change mine to conf-compile, but I'd like to
hear more widespread agreement first; I don't want to have to change
again later.

> The reason for package/sharing is that the installer can choose
> the sharing of sub directories. The package may suggest defaults in
> package/sharing but an installer can ignore these hints.

If an installer program makes separate files when package/sharing says
sharing is ok, then the installer is merely inefficient in its use of
space.  But if the installer shares files when package/sharing says
separate files should be made, then I'd say the installer is buggy.

Of course, a human admin can decide to share files even when
package/sharing says they should not be shared.  But a program should
not, at least by default.

> If the package has different sharing suggestions for similiar data
> it has to put it into different directories and add a line to
> package/sharing.

Right, but that doesn't address my question.  For example, consider
the current version of runwhen.  It contains a file
preconf/dep_libtai_include, whose first line specifies the path where
libtai header files are found.  How sharable is this file?  It's in
plain text format, and if you don't edit it, it's the same on every
platform.  But its purpose is to be edited when necessary, so it may
in fact be different on different systems.  The package author, who
creates package/sharing, cannot know how configuration files will be
edited by other admins.

I think it should be marked as "dist"-sharable, because any group of
systems that share files among each other will probably use the same
compile-time configuration, and because compile-time configuration
files have no effect after compilation, so it won't make any
difference how widely shared they are.

OTOH, run-time configuration files are influential after compilation,
and it seems more likely that they may be different even among systems
that share files.  So I think those should be marked as only
"host"-sharable.


paul