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/ 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 pgp9r3VMGXEdJ.pgp Description: PGP signature
Re: [ITA] _autorebase
On Dec 16 16:11, Ken Brown wrote: > On 12/16/2014 8:23 AM, Corinna Vinschen 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. > > More importantly, maintainers need to be told about the new kinds of > postinstall scripts now supported by setup.exe. (Or maybe that's what you > meant.) I actually only meant the new autorebase stuff, but you're oh so right about the requirement to document how the new postinstall stuff works. Achim, uhm... sorry abouyt that, but I guess we really have to improve https://cygwin.com/setup.html on that so all maintainers can educate themselves how to use the new feature. Fortunately the web pages are in CVS as well: cvs -d :ext:sourceware.org:/cvs/cygwin co htdocs Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDh_9nlr9NX.pgp Description: PGP signature
Re: [ITA] _autorebase
On Dec 17 10:39, Corinna Vinschen wrote: > On Dec 16 16:11, Ken Brown wrote: > > On 12/16/2014 8:23 AM, Corinna Vinschen 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. > > > > More importantly, maintainers need to be told about the new kinds of > > postinstall scripts now supported by setup.exe. (Or maybe that's what you > > meant.) > > I actually only meant the new autorebase stuff, but you're oh so right > about the requirement to document how the new postinstall stuff works. > Achim, uhm... sorry abouyt that, but I guess we really have to improve > https://cygwin.com/setup.html on that so all maintainers can educate > themselves how to use the new feature. > > Fortunately the web pages are in CVS as well: > > cvs -d :ext:sourceware.org:/cvs/cygwin co htdocs Oh, and there's something else very important. The new technique requires the users to update setup.exe, otherwise they will get problems. We can't do much for people ignoring the "this setup.ini has been created by a newer setup version" message in setup itself, but we should at least announce the new setup version. Achim, either you just write the complete announcement for setup from scratch, or you give me a piece of text to include into the announcement and I write it. Whatever you prefer. The important thing here is to urge people to upgrade. Given that many of us are not available the next 2 or 3 weeks (e.g., me), I'm wondering if we should let the new setup version sink in during that time, and upgrade the packages using the new feature (_autorebase, TeX Live) only in the new year, after the 6th of January when all of us will be back. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqFc7SzRKfb.pgp Description: PGP signature
Re: [ITA] _autorebase
On 12/17/2014 4:52 AM, Corinna Vinschen wrote: On Dec 17 10:39, Corinna Vinschen wrote: On Dec 16 16:11, Ken Brown wrote: On 12/16/2014 8:23 AM, Corinna Vinschen 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. More importantly, maintainers need to be told about the new kinds of postinstall scripts now supported by setup.exe. (Or maybe that's what you meant.) I actually only meant the new autorebase stuff, but you're oh so right about the requirement to document how the new postinstall stuff works. Achim, uhm... sorry abouyt that, but I guess we really have to improve https://cygwin.com/setup.html on that so all maintainers can educate themselves how to use the new feature. Fortunately the web pages are in CVS as well: cvs -d :ext:sourceware.org:/cvs/cygwin co htdocs Oh, and there's something else very important. The new technique requires the users to update setup.exe, otherwise they will get problems. We can't do much for people ignoring the "this setup.ini has been created by a newer setup version" message in setup itself, but we should at least announce the new setup version. Achim, either you just write the complete announcement for setup from scratch, or you give me a piece of text to include into the announcement and I write it. Whatever you prefer. The important thing here is to urge people to upgrade. Given that many of us are not available the next 2 or 3 weeks (e.g., me), I'm wondering if we should let the new setup version sink in during that time, and upgrade the packages using the new feature (_autorebase, TeX Live) only in the new year, after the 6th of January when all of us will be back. Good idea. I'll probably wait even longer than that with TeX Live, to give people plenty of time to get the new _autorebase working first. Ken
Re: [ITA] _autorebase
Corinna Vinschen writes: > Oh, and there's something else very important. The new technique > requires the users to update setup.exe, otherwise they will get > problems. We can't do much for people ignoring the "this setup.ini has > been created by a newer setup version" message in setup itself, but we > should at least announce the new setup version. > > Achim, either you just write the complete announcement for setup from > scratch, or you give me a piece of text to include into the announcement > and I write it. Whatever you prefer. The important thing here is to > urge people to upgrade. I'll look into that > Given that many of us are not available the next 2 or 3 weeks (e.g., me), > I'm wondering if we should let the new setup version sink in during that > time, and upgrade the packages using the new feature (_autorebase, TeX > Live) only in the new year, after the 6th of January when all of us will > be back. Good idea. In fact if we do that, I'd like to require either new releases for the packages using /etc/rebase/dynpath.d or alternatively that they get an additional package that drops just this file (if a full release _now_ would be too much work) and the requisite change to setup.hint to have a dependency added so that this new package gets pulled in. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITA] _autorebase
On Dec 17 18:01, Achim Gratz wrote: > Corinna Vinschen writes: > > Oh, and there's something else very important. The new technique > > requires the users to update setup.exe, otherwise they will get > > problems. We can't do much for people ignoring the "this setup.ini has > > been created by a newer setup version" message in setup itself, but we > > should at least announce the new setup version. > > > > Achim, either you just write the complete announcement for setup from > > scratch, or you give me a piece of text to include into the announcement > > and I write it. Whatever you prefer. The important thing here is to > > urge people to upgrade. > > I'll look into that > > > Given that many of us are not available the next 2 or 3 weeks (e.g., me), > > I'm wondering if we should let the new setup version sink in during that > > time, and upgrade the packages using the new feature (_autorebase, TeX > > Live) only in the new year, after the 6th of January when all of us will > > be back. > > Good idea. > > In fact if we do that, I'd like to require either new releases for the > packages using /etc/rebase/dynpath.d or alternatively that they get an > additional package that drops just this file (if a full release _now_ > would be too much work) and the requisite change to setup.hint to have a > dependency added so that this new package gets pulled in. That should be fine, given the rather short list of affected maintainers: octave Marco Atzeri perl Reini Urban/Achim Gratz ?!? php Yaakov Selkowitz python Jason Tishler/Yaakov Selkowitz RMarco Atzeri ruby Yaakov Selkowitz As for perl, are you still with us Reini? As for python, Jason, you're still around? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpv4TnXGD__c.pgp Description: PGP signature
Re: [ITA] _autorebase
Corinna Vinschen writes: > That should be fine, given the rather short list of affected maintainers: > > octave Marco Atzeri > perl Reini Urban/Achim Gratz ?!? > php Yaakov Selkowitz > python Jason Tishler/Yaakov Selkowitz > RMarco Atzeri > ruby Yaakov Selkowitz > > As for perl, are you still with us Reini? As for python, Jason, you're > still around? If Reini is still waiting for his machines to arrive or if some of the old packages need work, I can do the packaging. I'd just need help with the upload, I guess. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [HEADSUP Maintainers] setup.exe new postinstall facitilities
Ken Brown writes: > More importantly, maintainers need to be told about the new kinds of > postinstall scripts now supported by setup.exe. (Or maybe that's what > you meant.) Here's my original proposal again for reference: --8<---cut here---start->8--- 1. I'd like to move from suffix to prefix so that the scripts will list in approximately the order they are run. 2. I'd like to prepare for perpetual scripts, triggered scripts and general stratified postinstallation. 3. The implementation will at first only provide pre-postinstall and post-postinstall, both perpetual. Proper implementation of the things prepared for with 2. can then follow later. Here's how I think the prefixes should look like: naming convention: (-)?_
Re: [HEADSUP Maintainers] setup.exe new postinstall facitilities
> --8<---cut here---start->8--- I love the little ASCII art scissors.
Re: cygport patches for TeX Live
On 12/16/2014 6:08 PM, Ken Brown wrote:
Sorry, there was a stupid mistake in one of the patches. The corrected
one is attached.
This is embarrassing, but there was a mistake in a second patch also.
I'm reattaching the complete set of cygport patches, corrected.
I had made some minor changes after testing, and foolishly didn't bother
testing again before sending the patches.
Sorry
Ken
>From 9cb676f9e1e062f49d1364e7e60d8eb44be78907 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 25 Nov 2014 09:27:52 -0500
Subject: [PATCH 1/4] prep_texlive: remove references to /usr/share/texmf
This is no longer used as of TeX Live 2013.
---
lib/src_postinst.cygpart | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
index 9963b63..03311b9 100644
--- a/lib/src_postinst.cygpart
+++ b/lib/src_postinst.cygpart
@@ -371,7 +371,7 @@ __prep_texlive() {
_EOF
fi
- for d in /usr/share/texmf{-dist,}/fonts/{opentype,truetype,type1}
+ for d in /usr/share/texmf-dist/fonts/{opentype,truetype,type1}
do
if [ -d ${D}${d} ]
then
@@ -655,14 +655,10 @@ __prepetc() {
__prep_freedesktop_mime || error "Shared Mime Info postinstall
failed"
fi
- for d in /usr/share/texmf{,-dist}
- do
- if [ -d ${D}${d} ]
- then
- __prep_texlive
- break
- fi
- done
+ if [ -d /usr/share/texmf-dist ]
+ then
+ __prep_texlive
+ fi
if [ -d ${D}/usr/share/xsessions ]
then
--
2.1.1
>From 83b5ab484f9fe5e2550f6851cfa074d730d4b8bb Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Wed, 26 Nov 2014 07:35:13 -0500
Subject: [PATCH 2/4] prep_texlive: remove calls to mktexlsr
Instead create a marker file in /etc/texmf/postinstall indicating that
mktexlsr should be run by a perpetual postinstall script.
---
lib/src_postinst.cygpart | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
index 03311b9..9e4a910 100644
--- a/lib/src_postinst.cygpart
+++ b/lib/src_postinst.cygpart
@@ -328,11 +328,9 @@ __prep_mateconf_schemas() {
__prep_texlive() {
local d fmt fmts map maps
- dodir /etc/postinstall /etc/preremove
+ dodir /etc/postinstall /etc/preremove /etc/texmf/postinstall
- cat >> ${D}/etc/postinstall/${PN}.sh <<-_EOF
- /usr/bin/mktexlsr
- _EOF
+ touch ${D}/etc/texmf/postinstall/${PN}.lsr
fmts=$(__config_get texlive_fmts)
maps=$(__config_get texlive_maps)
@@ -351,7 +349,6 @@ __prep_texlive() {
cat >> ${D}/etc/postinstall/${PN}.sh <<-_EOF
/usr/bin/updmap-sys --nohash --syncwithtrees
/usr/bin/updmap-sys --nohash
- /usr/bin/mktexlsr
_EOF
fi
if [ -n "${fmts#0}" ]
@@ -366,9 +363,6 @@ __prep_texlive() {
/usr/bin/fmtutil-sys --disablefmt $fmt
_EOF
done
- cat >> ${D}/etc/postinstall/${PN}.sh <<-_EOF
- /usr/bin/mktexlsr
- _EOF
fi
for d in /usr/share/texmf-dist/fonts/{opentype,truetype,type1}
--
2.1.1
>From 5a2d076c5b55014342104d5327b80b62b9cf6f06 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Wed, 26 Nov 2014 07:53:29 -0500
Subject: [PATCH 3/4] prep_texlive: remove calls to fc-cache
Instead, create a file in /etc/texmf/postinstall listing the font
directories on which fc-cache should be run by a perpetual postinstall
script.
---
lib/src_postinst.cygpart | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
index 9e4a910..a486d44 100644
--- a/lib/src_postinst.cygpart
+++ b/lib/src_postinst.cygpart
@@ -369,8 +369,8 @@ __prep_texlive() {
do
if [ -d ${D}${d} ]
then
- cat >> ${D}/etc/postinstall/${PN}.sh <<-_EOF
- /usr/bin/fc-cache -f $d
+ cat >> ${D}/etc/texmf/postinstall/${PN}.fc <<-_EOF
+ ${d}
_EOF
fi
done
--
2.1.1
>From 547c70536ad878aa04b77b97cf7b4e7d8db758da Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Fri, 28 Nov 2014 10:47:49 -0500
Subject: [PATCH 4/4] prep_texlive: group enable/disable commands in calls to
updmap
In postinstall scripts we remove the updmap calls completely and
instead create a file of commands in /etc/texmf/postinstall, to be run
by a perpetual postinstall script. In preremove scripts we just group
the commands into a single call to updmap, since setup.exe doesn't yet
support perpetual preremove scripts.
---
lib/src_postinst.cygpart | 16 --
