Re: Packaging questions (cricket)
Le Sun, Aug 22, 1999 at 07:00:37PM -0400, Matt Zimmerman écrivait:
> |-- doc (documentation)
> | `-- neta-paper
> |-- images (used by the CGI)
An already used solution was to put them in /usr/doc/<package>/ and then
the images were available as /doc/<package>/<image> in the web tree.
But this is likely to fail now that we're going to change /usr/doc with
Therefore the best solution is propbably to install them directly under
/var/www I think. Or install them in /usr/share and put symlink in
> |-- lib (Perl modules used internally)
> | |-- Common
> | |-- ConfigTree
> | `-- RRD
somewhere in /usr/share/
> |-- sample-config (a sample configuration tree)
> `-- util (auxiliary and example programs called to do data collection)
You should decide whether they are only examples or not. :)
> - Configuration tree in /etc/cricket
> - 'compile' (a program to convert the ASCII configuration into a database
> format for use internally) in /usr/sbin as 'cricket-compile'
if the user is not intented to call it directly, then simply put it in
/usr/lib/cricket/compile and call it where necessary. :)
> - 'collector' and friends (all architecture-independent) installed in
> /usr/share/cricket and called from a cron job (conffile /etc/cron.d/cricket)
> - Perl library modules under /usr/share/cricket/lib
> - Documentation and examples in /usr/doc/cricket
Until the technical committee decides that we can switch to
> - CGI programs in /usr/lib/cgi-bin/cricket
> I have not yet decided what to do with the images...policy states that
> packages should avoid touching the web server document root. Should
> I install them under /usr/share/cricket and tell the user to Alias that
> directory to /cricket/images with the web server or some such?
No, the package should we working when installed. Install the images in
/usr/share/cricket/images and symlink /var/www/cricket/images =>
> Also, this package needs a UID for the collector to run under, as it needs to
> create database files, etc. How should this be handled, and in which
> installation script? Should I ask the user what to do, or create a user
I've got a similar problem for the package sympa. I automatically create
the user in the postinst after checking that it doesn't already exist.
You can take a look at this package since it does also use a bunch of perl
modules and scripts which are in general automatically installed in a
/home/sympa dir ...
> the desired username is being used for local purposes, in which case I imagine
> that Squid would break badly. Should I try to detect this situation (that is,
> whether the user was created by my package or by the local admin, and act
> appropriately), or is squid doing the right thing?
I don't take care of this problem. It is not likely to happen ...
> To find where they are installed, so as to locate the 'lib' directory
> immediately beneath. This actually works OK for the collector (in
> /usr/share/cricket), as it will find the correct 'lib'. For 'compile',
> I manually edited it to use /usr/share/cricket as its 'root'. This part
> is kind of a mess.
I also had similar problems, I simply wrote a patch which does allow to
decide at install time where everything is installed and asked the author
to include it.
> Lastly (for now ;-) ), the collector will need a logfile to write to, so that
> the user can tell what is going on. The correct prodedure for this would seem
> to be:
> - Have the collector write its logfile to /var/log/cricket
With /var/log/cricket a directory. The log file beeing
/var/log/cricket/cricket.log. This way you are sure that you have write
permission to the log file. :)
> - Add a conffile /etc/logrotate.d/cricket to have the logfile rotated in
> a reasonable default way
> Since logrotate is not essential, I will have to depend on it somehow. While
> log rotation is not required for the package to be functional, its logging is
> pretty verbose, and if left unattended the logfile can grow quite large (I use
> Cricket extensively at work, and my configuration generates about 24mb of
> logfiles per week). Should I Recommend or Suggest logrotate? Recommend
> seems more appropriate to me, so that the unwary do not have their
> disks filled.
Yes recommends seems good. Anyway logrotate is important so should be
installed with fresh install.
> This should be quite a good learning package, no? ;-)
Raphaël Hertzog -=- http://ntux.u-strasbg.fr/~raphael/
<pub> CDs Debian : http://ntux.u-strasbg.fr/~raphael/debian/#cd </pub>