[Dirvish] TODO for Dirvish

Paul Slootman paul at debian.org
Fri Dec 17 07:28:22 PST 2004


On Thu 09 Dec 2004, Eric Mountain wrote:
> 
> 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).

One thing that must be taken care of, is that there is some way to let
"make install" put the files into another location than where they
should go; building a package suitable for distribution entails
installing into a tmp directory, which is then packaged. That's usually
done by setting DESTDIR or PREFIX, but sometimes the Makefile needs to
hacked :-(

As for application config files (I guess you mean runtime config stuff),
it's pretty hard in the case of dirvish to give sane defaults... The way
I've done it in the Debian package is to put an example in the docs.

> > 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.

Agreed, this is a end-user configuration issue, and needing to have the
source available to configure the package is silly.


Paul Slootman


More information about the Dirvish mailing list