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


On Dec 16 17:24, Achim Gratz wrote:
> > 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.

Thanks!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpaBM1wTnlG5.pgp
Description: PGP signature


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