This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [HEADSUP Maintainers] _autorebase


> 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.  The remainder of the package ensures that
autorebase is run each time the user runs setup.  Ad 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 1: 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 /etc/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.

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 /etc/rebase/dynpath.d/perl, which
would have a single line containing the path /usr/lib/perl5/site_perl.

Currently autorebase delivers these files in /etc/rebase/dynpath.d:

octave
perl
php
python26
python27
R
ruby

If your package is going to provide one of these files in a later
release, please coordinate via cygwin-apps that it gets removed from
_autorebase together with that release.

Note 2: It would still be time to orchestrate package updates so that
the initial release of _autorebase did not include those files.
Especially for Perl that might mean we'd have to patch the package
archive, however.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]