autorebase and user-installed dynamic objects

[Achim Gratz]

Achim Gratz writes:
> Ken Brown via Cygwin-apps writes:
>> I've taken a stab at this (attached).
>
> I'm a bit short on time right now, but my plan is to remove the user.d
> functions from rebaselst and instead implement an option that will make
> it work on non-system files (e.g. user directory).  That should cut down
> on code duplication I hope and make it easier to later take advantage of
> an updated rebase that can work with more than one database.

I have an interim update that works more or less like the current
implementation plus some fixes to be more resilient against filenames
containing spaces somewhere (I'd appreciate if somone would actually
test that this works), but allows to have more fine-grained control over
the locations or files to be rebased (changed documentation below).  The
.eln suffix is already included in the list of extensions.  This only
works on systems where the user directory is fully accessible to setup,
as it will still be done during the normal autorebase step.  Any
user-specific rebase that caters to those installations that do not
fulfill that requirement will have to wait for the requisite support in
rebase to appear.  Point setup to use this additional install source:

root=http://cygwin.stromeko.net/
$root/stage

and install the test package for _autorebase contained therein.

--8<---------------cut here---------------start------------->8---
_autorebase
===========

This package provides scripts to keep the Cygwin system properly
rebased.  By default this happens incrementally, which means only
dynamic objects that have been installed after the last run of rebase
will be considered and the current rebase map takes account of the
already rebased parts of the installation.  The scripts must be run by
the system administrator or from another account that has all the
necessary access rights.

Over time the rebase map can fragment.  By triggering a full rebase,
all dynamic objects on the system are treated as newly installed and
the existing rebase map is cleared before doing the rebase.  To
perform a full rebase, execute "rebase-trigger fullrebase".  Then shut
down Cygwin including any services you have installed and simply run
setup.exe.  The rebase will be performed even when the installation
did not get modified in any way.  Subsequent runs of setup.exe will
again rebase in incremental mode.

Some programs allow the user to create or install dynamic objects
after installation.  Since these are not part of an installed package,
they wouldn't be rebased automatically, as their location isn't known
to the package system. Entire subtrees to be searched for dynamic
objects can be advertised in /var/lib/rebase/dynpath.d/,
/var/lib/rebase/localpath.d/ and /var/lib/rebase/userpath.d/ for
packaged paths, locally provided paths and user paths, respectively.
The format of files in these directories is one absolute path per
line.  The list of suffixes that files need to have to be considered
dynamic objects in these locations is hardcoded as
"dll|so|eln|oct|mex".  Files that should be rebased, but do not have
one of these suffixes can be advertised in /var/lib/dynfile.d,
/var/lib/localfile.d and /var/lib/userfile.d for packaged files,
locally provided files and user files, respectively.  The format of
files in these directories is one absolute file name per line.
Packagers should name their files after the (main) application package
that creates the dynamic objects at the advertised location and must
not package anything in either the local*.d or user*.d directories.
The local system administrator should only place files in local*.d
directories and otherwise keep the naming scheme as used for packages.
The user*.d file names should start with the account name of the user
the advertised locations belong to.

The user running the installation must have full access rights to all
such paths and all such locations must be available (e.g. remote or
encrypted volumes must be mounted and unlocked, respectively).

The incremental rebase is controlled by the script /usr/bin/rebaselst.
Except for debugging purposes this script should not be run directly
by users.  Like any other attempt at rebasing it doesn't work
correctly on a live Cygwin system.
--8<---------------cut here---------------end--------------->8---


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada