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] |
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] |