| [Index] [About] |
| |||||||
|
||||||||
Introduction
Version 1.2 of pkg-tools has brought templated package control scripts into being. The reason for this was simple; I had been maintaining a gaggle of functions which could do things like add entries to the default PATH variables, place files under rcs control, add entries to /etc/syslog.conf, etc.
Over time I found that maintain all of the various package control scripts with up to date versions of the functions was quite time consuming so I decided to do something about this. There are two different ways this problem could be solved:
Define a set of functions to be used in a set file and have every package control script pull that file into it when it ran. The problem here is that package control scripts must be written in sh. It is possible to pull a file of functions into a running sh script via the use of something like:
eval "`cat /usr/local/lib/pkg-tools/package-functions.sh`"However the only problem with that is that the file /.../package-functions.sh would have to exist on a system before a package which made use of scripts which called it could be installed. Whilst its possible to ensure this by placing the /.../package-functions.sh in a package of its own and place a dependancy on that package in all packages which used it, it is not a very good solution since the file can still be remove via the use of rm.
Define a set of functions which are placed into a template file. Template package control scripts are then turned into real package control scripts when the package is built.
The advantage of this is that you can take a package and put it directly onto a machine. The disadvantage is that when you update the main template file you have to update lots of packages at the same time.
Both methods have their advantages, however I prefer the build a complete package control script which doesn't rely on any other code. Whilst you do have to maintain all of the packages with up to date versions of the master template file, this can be easily scripted. However putting the code to be used onto the systems themselves means that you have to do lots of work with the end systems if you update the master funxtion file.
Using the system
I've tried to make the system as easily to use as possible:
- The simple-proj script with now place the templated package control scripts into the InstallPackage directory it creates.
- The build-pkg script automatically calls the template-control script when it is run to turn the package control script template files into the real package control scripts.
- The update-pkg script also calls the template-control script to re-build the package control scripts when it pulls apart the datastream packages build-pkg creates to update the package control scripts.
For new packages...
With new packages you can just take the following route:
% simple-proj % build-pkg ...The call to simple-proj creating the InstallPackage directory with the default postinstall.template and postremove.template files pulled from /usr/local/lib/pkg-tools/simple-proj/std.
For existing packages...
Existing datastream packages can be updated by just calling the update-pkg script, assuming that you're in a directory which has a InstallPackage directory within it which contains suitable template files for the package concerned.
|
||||||||
|---|---|---|---|---|---|---|---|---|
| [Index] [About] | Powered by WML |
| ||||||
|
||||
| © Simes |