[Dirvish] TODO for Dirvish
em-dirvish-1 at nerim.net
Wed Dec 8 15:04:43 PST 2004
On Wednesday 08 Dec 2004 01:05, Keith Lofstrom spake thus:
> Dirvish involves a fair amount of configuration, and eventually (NOT ON THE
> FIRST NEW VERSION!!!) this should be compatable with the generation
> of configuration files and documentation.
> one thing a ./configure script and a makefile should be able to
> do is generate some site-specific documentation, if nothing more than
> a 30 line file with software version numbers and file locations and
> the like.
Distributions have the tools to provide software version and file location
information dynamically. For instance, on Debian:
- "dpkg -L dirvish" lists all the files owned by the dirvish package.
- "dpkg -s dirvish" gives me software dependencies, package installation
...and of course there are nice GUI tools which can display loads more
information in nice ways, e.g change logs.
Of course, this doesn't cover "./configure && make install" installations, but
there is *AFAIK* no really standard way to store such information for this
type of setup.
Generating *application* config files is another story altogether. We could
make dirvish configuration a part of dirvish itself. Ideally, we should play
nice with the distributions and make it easy for them to call our
configuration scripts/modules/whatever (maybe Paul Slootman can advise on how
to best go about doing this).
> The ./configure script should check for the necessary perl modules, and
> for incompatable perl and ssh and rsync versions. A second generation
Definitely. This is the kind of thing that ./configure is designed to do.
> script would check the ssh connections to the target machines. A third
> generation script would help design the structure of backups and storage,
> and perhaps import existing backups onto the backup disks. While those
> later generations are hypothetical, and yet to be designed, I don't want
> to exclude them by the design choices we make now. Treat that as a design
This looks like it is out of scope for ./configure: autoconf's job is to
provide the means to prepare the build and installation. The installation
might take place on a different machine (in particular if a package is being
built for distribution). OTOH, this could definitely be a part of the
generation of application config files.
Here's a brief summary of the configure, build, install and application
configuration stages - maybe it helps picture what steps ./configure and make
intervene in. (Important note: please don't get the impression I know how to
set this up, nor the details of what needs doing ;-). It looks like Doug
Hanks' previous experience would be valuable in this area!)
Stage 1: Build
- ./configure: checks software versions present on build machine, generates
config files necessary for build step.
- make: builds the software
Stage 2: Install, or generate package for distribution
- make install: installs the software (if this a package is being built for
distribution, then this will install the software into a fake root directory)
- [distributions only] build package for distribution
- [distributions only] install package
- Configure Dirvish: design backup config, check remote dependencies, etc.
More information about the Dirvish