I'll be a little more specific.
I want to have different versions of a package installed. This package
needs an RC file, and verious programs in the package need to call each
other.
There are cron jobs that need to be run on behalf of the package, and it
runs network daemons that call programs. The package may have a daemon that
is run out of inetd.
(Hmmm, I can look at amanda...).
Anyway, I'm thinking that it would be Useful to have a section in some
document (coding standards or whatever) that says something like:
- When a process starts up and it needs to do some RC file processing, it:
- - first looks for an optional environment variable
- - looks for a command line argument
- - processes rc files in the order:
- - - $prefix/wherever/rc
- - - ~/rc.package
- - - ./rc.package
I remember a few years ago folks deciding that it was best to process the RC
files *twice*, so that subsequent (more specific) RC files could override
choices made by earlier (more general) RC files, and there was a Good Reason
to process the list twice. But I'm fuzzy on this one.
I'd like to see a little discussion about the best way to tell a daemon
where to find other package-specific (possibly version specific) executables
- should the paths be hardcoded in the RC file, or should there be a PATH
spec in the RC file?
Has anybody written a library to help with things like this?
H
