[Dirvish] TODO for Dirvish

Eric Mountain 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 
status, etc.
...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
> constraint.

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

Stage 3:
 - Configure Dirvish: design backup config, check remote dependencies, etc.


More information about the Dirvish mailing list