The following is an except from a correspondence with Josip Rodin, who has been advising me on packaging matters. He suggested that I forward my questions here for more feedback.
Thanks for any help... ----- Forwarded message from Matt Zimmerman <[EMAIL PROTECTED]> ----- Date: Sun, 22 Aug 1999 14:57:56 -0400 From: Matt Zimmerman <[EMAIL PROTECTED]> To: Josip Rodin <[EMAIL PROTECTED]> Subject: Re: Bug procedure On Sun, Aug 22, 1999 at 02:21:15PM +0200, Josip Rodin wrote: > On Fri, Aug 20, 1999 at 03:09:28PM -0400, Matt Zimmerman wrote: > > I have started working on a new package, for the Cricket data collection > > and display software <http://www.munitions.com/~jra/cricket/>. I am > > [...] > Great! If you need any assistance from me, just say. Well, I'd like your feedback on the directory structure I'm experimenting with. Cricket is a collection of Perl programs used to 1) gather data from various sources (e.g. SNMP, script output, etc.) and store them in a database (provided by the soon-to-be rrdtool package) and 2) retrieve and display these data in a graphical format via a CGI program. The "usual" installation procedure (as described in the program documentation) is to untar the distribution into a dedicated user's home directory, run a script to substitute the correct location of the Perl interpreter, and symlink the CGI part into a directory that is part of the web namespace. The directory structure looks something like this: cricket-0.70 |-- doc (documentation) | `-- neta-paper |-- images (used by the CGI) |-- lib (Perl modules used internally) | |-- Common | |-- ConfigTree | `-- RRD |-- sample-config (a sample configuration tree) `-- util (auxiliary and example programs called to do data collection) The user-visible part of the package is installed in the cricket-0.70 directory, and consists of programs like 'compile', 'collector', 'grapher.cgi', etc. Most of these programs are not called interactively, and have very generic names, which makes me very hesitant to put them in /usr/bin. My current plan is this: - 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' - '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 - CGI programs in /usr/lib/cgi-bin/cricket - Databases in /var/lib/cricket --- postscript: I have since changed this to /var/state/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? 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 without prompting? I looked to other packages for examples, and found that squid creates a 'proxy' user (in preinst) without prompting, so I gave my package that behavior for the time being (though I am using postinst). If the user already exists, a message is printed explaining the situation, and no changes are made. I noticed that the squid package just exits silently if the 'proxy' user already exists...it seems that this does not handle the case where 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? The other interesting part is its methodology for finding its configuration. The scripts do a little Perl-ism: $Common::global::gInstallRoot = (($0 =~ m:^(.*/):)[0] || "./") . "."; 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. One of the library modules is used to read the configuration, and it does the following: my($base) = "$ENV{'HOME'}/cricket-config"; GetOptions( "loglevel:s" => \$logLevel, "base:s" => \$base, @_); Common::Log::setLevel($logLevel); $Common::global::gConfigRoot = $base; It seems that my options are (at least): - Change the initial default of $base, in the declaration, to be /etc/cricket (this is somewhat intrusive, but is what I have been using for testing and it works well) - Replace the Cricket programs with a wrapper script that calls them with the options '--base=/etc/cricket' (this would break in the event that a user would want to actually use the tools with an alternate configuration, for instance when testing) - Arrange for a symlink to be created in the cricket user's home directory, called 'cricket-config', pointing to /etc/cricket. This breaks when the tools are called by any user other than Cricket, and is messy. What would you recommend? 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 - 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. This should be quite a good learning package, no? ;-) -- - Matt ----- End forwarded message ----- -- - Matt
