On Tue, Mar 11, 2003 at 12:24:38AM +0100, Robert Joop wrote:
> i don't think the tool is a problem, but the concept is...
> what kinds of configurations do we need for the a least three flavors
> (installs from source, from rpms and from debs)?

All thats needed is:

a) a way to install the package without installing any site specific
config files.

b) a way to configure these site specific commands on demand.

> i use deb packages, but i've never packed one.

Don't worry about that, I have packaged openca for Debian, its just that
iis is mostly useless at the moment, because the config is hardcoded to
something noone would want to use.

So I would suggest:

1. generate list of site specific variables, eg: country, organisation,
etc. Probably a good starting point is with:

grep AC_SUBST configure.in

however, some of these won't be required. Just guessing here, but
I think
- *_url_prefix is required.
- VERSION, TODAY, *_prefix, *_user, *_group NOT required.
- package_build, PERL_MAKEFILE_OPTS, perl_use_lib are NOT required.
- sendmail,openssl_engine are optional, some users might want to use a
  locally compiled version for some reason I can't understand.

there might be others I missed.

2. it might be possible to automatically calculate some variables
based on other variables, eg. hierarchy_level automatically determines
values for a number of other variables (or so it would appear). These
automatically calculated variables do not need to go in the config file
(unless you really want them to).

3. For all *.in files, replace these variables with @...@ notation
with #...# notation. So @httpd_host@ would become #httpd_host# for
instance.

4. Instead of installing these files in /etc/openca, install them in
either:
   - /usr/share/openca/example/...      (if source files are static and
                                        should not be changed)
   - /etc/openca.in/                    (otherwise)

The first would prohibit making any changes after initial installation
without replacing all config files from scratch, the second would allow
editing the files under /etc/openca.in/, and having the changes take
place after rebuilding. Both methods have pros/cons.

(note: under Debian policy user-modifiable config files can only go
under /etc, otherwise they will be replaced without any warning on the
next upgrade).

5. Have a perl function (or whatever) that processes all files in the
source directory, applies the config file, and outputs the result into
/etc/openca/*

This should work the same regardless of what distribution or
packaging system is used.
-- 
Brian May <[EMAIL PROTECTED]>


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel

Reply via email to