Re: [HEADSUP Maintainers] setup.exe new postinstall facitilities

[Achim Gratz <Stromeko at nexgo dot de>]

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