[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging questions (cricket)

Le Sun, Aug 22, 1999 at 07:00:37PM -0400, Matt Zimmerman écrivait:
> cricket-0.70
> |-- doc (documentation)
> |   `-- neta-paper

=> /usr/share/doc

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

/usr/share/doc/examples :)

> `-- 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
/usr/share/doc. :)

> - 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 =>
/usr/share/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? ;-)

Yes. :)

Raphaël Hertzog -=- http://ntux.u-strasbg.fr/~raphael/
<pub> CDs Debian : http://ntux.u-strasbg.fr/~raphael/debian/#cd </pub>

Reply to: