Ken Brown writes: > More importantly, maintainers need to be told about the new kinds of > postinstall scripts now supported by setup.exe. (Or maybe that's what > you meant.)
Here's my original proposal again for reference: --8<---------------cut here---------------start------------->8--- 1. I'd like to move from suffix to prefix so that the scripts will list in approximately the order they are run. 2. I'd like to prepare for perpetual scripts, triggered scripts and general stratified postinstallation. 3. The implementation will at first only provide pre-postinstall and post-postinstall, both perpetual. Proper implementation of the things prepared for with 2. can then follow later. Here's how I think the prefixes should look like: naming convention: <stratum><type>(-<trigger>)?_<script name>.<suffix> stratum := [0-9a-z] type := [pqrt] trigger := [a-z]+ Non-prefixed scripts will be run someplace in the middle of things (probably at _i_nstall). The type encodes _p_erpetual, _q_uery, _r_unonce and _t_triggered and on each stratum the scripts get run in that order. Trigger names are allowed, but not acted upon for perpetual and runonce scripts, so you can use these as a namespace for postinstall scripts that should belong together. A query script causes all triggered script in run sequence after it and with the same trigger to be run when it returns true. --8<---------------cut here---------------end--------------->8--- At the moment the only thing that has been implemented is the 0p and zp prefix (i.e. stratum 0 and z and type p) without queries and triggers. These allow a package to specify a postinstall action that gets executed _each time_ setup is run as long as the package is still installed (perpetual postinstall scripts). Depending on the stratum, these postinstall scripts get run either before (stratum 0) or after (stratum z) the conventional, run-once scripts. Not directly related to this change is the ability to use dash instead of bash for scripting when the script uses a ".dash" suffix (you need to "export PATH=/bin" in those scripts). Also, CMD command files can now have a ".cmd" suffix in addition to plain old ".bat". As a consequence, if your package only needs run-once scripts for postinstall actions, then you don't need to know about the perpetual scripts, except that you must not use any script name that matches the regex "^[0-9a-z][pqrt]_". For those package maintainers wanting to employ perpetual scripts, the first thing to keep in mind is to only use this feature for things that really can't be done with run-once scripting, so this will likely require an extensive re-write of the current postinstall logic. Any perpetual script should minimize the resources used (use dash instead of bash for instance) and exit at the earliest possible moment if no action is required. Scripts on stratum 0 at the moment must be able to run with the Base packages just installed, but the postinstall scripts not yet executed (in practical terms that rules out using bash scripts). This limitation does not apply to stratum z scripts obviously. In all but the most simple cases the perpetual script will check for some condition created by a package install or de-install and then decide what actions to take. Since triggers have not yet been implemented, coordination among packages using the same perpetual script will have to use "marker" files. These markers can be files created during install (like /etc/setup/<package>.lst.gz) or files that are dropped by the package. Do not be tempted to drop the same file from multiple packages, since deinstallation of one of those packages will break all the other packages. Keep in mind that the time-stamp on a file installed by a package has no relation to the install time. As a practical example, consider a package with three optional sub-packages. Depending on which of those sub-packages are present, a configuration needs to be created. Let's assume that the configuration process takes a lot of time, so running it three times during postinstall isn't a good idea. Besides, if the user removes a sub-package later without installing another one, then your configuration would become stale. You could instead use a stratum z postinstall script that does the following things: 1. Check for presence of /etc/setup/<package>-option[123].lst.gz to figure out which sub-packages are present. 2. Check if a configuration has been created before (via another file, for instance) and whether the set of sub-packages was the same. 3. Exit if the configuration hasn't changed, otherwise record the new set of sub-packages that are installed and start the configuration process. This way, the configuration is kept up-to-date with the installed packages with the minimum number of configuration runs. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
