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