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 /usr/share/doc. 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 /var/www/ > |-- 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 ok. > - '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) ok. > - Perl library modules under /usr/share/cricket/lib Good. > - 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 ok. > 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 Yes. > 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. :) Cheers, -- Raphaël Hertzog -=- http://ntux.u-strasbg.fr/~raphael/ <pub> CDs Debian : http://ntux.u-strasbg.fr/~raphael/debian/#cd </pub>
