[HEADSUP Maintainers] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> What would be most helpful is to get a piece of documentation for us
> maintainers how to use the new _autorebase facility, sent with a fat
> HEADSUP subject, and which we can ideally add to setup.html.

The _autorebase package is designed to require no intervention from a
package maintainer in most cases.  The core of the work is done by the
rebaselst script.  It works mostly like the rebaseall script, but tries
to rebase only files that have been changed since the last time
autorebase was run (it keeps the information to do this in
/var/cache/rebase).  The remainder of the package ensures that
autorebase is run each time the user runs setup.

An additional script rebase-trigger allows the user to request a full
rebase of the installation on the next execution of setup.  Both scripts
are self-documenting when invoked with an option of -h or --help.

Note: It's possible to run rebaselst manually if you know what you're
doing.  At the moment I don't want to advertise or support that,
however.


There are two exceptions that require maintainer attention:

1. Your application uses dynamic objects that have a suffix not matched
by "dll|so|oct|mex".  There currently aren't any such applications, but
if you plan to introduce one, please discuss on cygwin-apps first.

2. Your application allows users to install dynamic objects into
site-specific directories.  Since autorebase relies on the information
in /etc/setup, it would miss to rebase these objects since they aren't
part of any package.  If you maintain such an application, please add a
file /var/lib/rebase/dynpath.d/<package> that contains one absolute
directory path per line that autorebase should search for dynamic
objects to rebase.

Do not include those directories that packages are using and keep them
separate from those that site installations are going to.  If
user-installed and packaged files are shared in the same path,
_autorebase will need to check them each time setup is run, which
increases runtime.  The rebase database ensures that each file is
handled only once.  This is based on the path name, so you must ensure
that the same file doesn't get fed to rebase via two different paths.

As an example, Perl packages modules into /usr/lib/perl5/perl_vendor,
while site modules will go into /usr/lib/perl5/site_perl.  Only the
latter will need to be maintained via /var/lib/rebase/dynpath.d/perl,
which would have a single line containing the path
/usr/lib/perl5/site_perl.

Currently these files should be in /var/lib/rebase/dynpath.d if the
corresponding packages are installed:

octave
perl
php
python26
python27
R
ruby

Your package must provide one of these files when or before the
autorebase package gets released.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds