[Dirvish] restructuring the dirvish install process

Paul Slootman paul at debian.org
Fri Dec 17 07:38:00 PST 2004

On Fri 17 Dec 2004, Keith Lofstrom wrote:
> Right now, dirvish is installed with a shell script, that 
>   1)  Asks where the software should be installed
>   2)  builds the executables by concatenating some .pl files
> Doug Hanks has noted that this can be done in a more standard way with
> a makefile.  Good observation.  Lets adhere to some standards.
> The install process must *still* ask where the software should be 
> installed.  I put mine in /usr/local/sbin;  /usr/local/bin is also
> an option.  Some folks want /bin, /sbin, or elsewhere .   Another
> issue is where the master.conf file goes.  Some folks may want
> something besides /etc/dirvish .  These choices should be respected
> by the install.

The phrase "must still ask" implies to me interactivity. Distribution
builders won't want that... I now echo a string to the configure script
that gives the right responses, but that's pretty sucky to maintain.
Being able to pass "answers" via options or environment variables is
pretty much a "must" IMHO.

> Rather than concatenating files, we should make more standard usage
> of Perl and common modular design practices by putting the subroutines
> that are used in more than one executable (like loadconfig and seppuku)
> into a library or module.  Since dirvish uses Time::Parsedate and
> Time::Period, which are not unsually included in the basic Perl
> distribution, the install process should pull those from CPAN if
> needed.  The versions of perl and rsync and ssh used should be noted
> and probably tested.

Mostly a minimum version number is required, which could be determined
by e.g. rsync --version.  Make this testing overridable though, as when
building a package for a distribution it would be silly to require e.g.
rsync to be installed.

> Most perl packages have a makefile.pl that takes care of these things.
> Most perl packages also test themselves during an install.  We should
> be making man pages,  but it is more standard to make pod and info files
> for perl and gnu packages respectively.  How do you folks want your
> documentation served?

Debian requires manpages to be available. That's my preferred format as
well :-)

Paul Slootman

More information about the Dirvish mailing list