From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: postinstall: fontconfig abnormal exit
Date: Sat, 12 Sep 2020 08:56:24 -0400 [thread overview]
Message-ID: <9c515b79-42e2-5a9b-1996-9281f3c2b0e8@cornell.edu> (raw)
In-Reply-To: <abb3d78e-7679-db16-e219-7e32b04942c0@SystematicSw.ab.ca>
On 9/12/2020 1:18 AM, Brian Inglis wrote:
> On 2020-09-11 15:13, Ken Brown via Cygwin wrote:
>> On 9/11/2020 4:30 PM, Achim Gratz wrote:
>>> Ken Brown via Cygwin writes:
>>>> Unfortunately, this doesn't yet fix the problem with
>>>> fontconfig_dtd.sh. The latter will now succeed if it is run after
>>>> libxml2.sh, but not if it is run first. I'm not aware of any way to
>>>> force setup to run one postinstall script before another.
>>>
>>> Multiple ways:
>>>
>>> 1. Make the libxml postinstall script sort lexically before any others
>>> that depend on it. Obviously this is brittle, but it might work in this
>>> particular instance (autorebase does this).
>>>
>>> 2. Make the libxml catalog creation a perpetual postinstall script with
>>> prefix "0p_". That only works if it doesn't depend on other postinstall
>>> scripts having their work completed.
>>>
>>> 3. Implement and use the stratified postinstall concept originally
>>> outlined at:
>>> https://sourceware.org/legacy-ml/cygwin-apps/2014-12/msg00148.html
>>>
>>> 4. Use the package dependency order to order the postinstall script
>>> activation. With libzypp we should have the correct information, we'd
>>> just need to somehow make the packagemeta iterator use it. That still
>>> won't work if we have dependency loops.
>>>
>>> 5. (Try to) Run any failed postinstalls again in setup and bail only if
>>> the number of fails does not decrease from the last iteration.
>>>
>>> At the time it was deemed too complicated and so we only use the "end"
>>> strata for the perpetual postinstall scripts. As said then, there would
>>> need to be some serious discussion on how to coordinate the strata
>>> assignments.
>>
>> There's no dependency relation between libxml2 and libfontconfig-common, so #4
>> wouldn't fix the problem. And some of the other suggestions would require work
>> on setup.exe that someone would have to do. The current problem is simple to
>> fix and shouldn't have to wait for that.
>>
>> I like your idea of using perpetual postinstall scripts. I think the way to do
>> it is probably to make fontconfig_dtd.sh perpetual with prefix "zp_". That way
>> if libfontconfig-common is installed without libxml2 but then libxml2 is
>> installed later, the xmlcatalog command gets run. We would have to check that
>> no harm is done if that xmlcatalog command gets run more than once.
>
> As libxml2 supplies /usr/bin/xmlcatalog, that postinstall script should both
> conditionally create the catalog and only if just created, also conditionally
> add fonts.dtd,
No, the libxml2 postinstall script shouldn't add fonts.dtd. That should be
added only when/if fontconfig is installed. So it's an appropriate task for a
fontconfig postinstall script.
> [TL;DR: We do not want to add more permanent postinstall scripts unless essential!
Making fontconfig_dtd.sh perpetual may or may not be essential, but it's the
best way I can think of to solve the problem of this bug report. Can you
propose a better way?
> Permanent postinstall scripts can greatly extend the run time of the Cygwin
> Setup program, when fontconfig, man-db, or tex just seem to decide sometimes for
> some reason that another whole new world of fonts, man pages, or whatever has
> appeared that they have to reprocess,
If you see a perpetual postinstall script doing something time-consuming that
you think is unnecessary, please make a bug report.
> pushing the Setup run time and service
> (cron) downtime to hours
I've never seen this. Please give details.
Ken
next prev parent reply other threads:[~2020-09-12 12:56 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 6:43 Fergus Daly
2020-09-08 12:03 ` Hamish McIntyre-Bhatty
2020-09-08 14:16 ` Andrey Repin
2020-09-08 15:18 ` Fergus Daly
2020-09-08 16:14 ` Brian Inglis
2020-09-10 5:23 ` Fergus Daly
2020-09-10 5:35 ` Andrey Repin
2020-09-10 10:57 ` Fergus Daly
2020-09-10 14:40 ` Brian Inglis
2020-09-11 6:04 ` briand
2020-09-11 7:22 ` Fergus Daly
2020-09-11 8:32 ` Hamish McIntyre-Bhatty
2020-09-11 11:31 ` Marco Atzeri
2020-09-11 13:12 ` Ken Brown
2020-09-11 14:41 ` Marco Atzeri
2020-09-11 19:47 ` Ken Brown
2020-09-11 20:30 ` Achim Gratz
2020-09-11 21:13 ` Ken Brown
2020-09-12 5:18 ` Brian Inglis
2020-09-12 12:56 ` Ken Brown [this message]
2021-07-20 17:00 ` Brian Inglis
2021-07-21 19:26 ` Ken Brown
2021-07-23 3:37 ` Brian Inglis
2020-09-12 6:08 ` ASSI
2020-09-13 16:53 ` Ken Brown
2020-09-16 8:42 ` Fergus Daly
2020-09-12 18:16 ` Andrey Repin
2020-09-14 15:47 ` Hamish McIntyre-Bhatty
2020-09-11 13:18 ` Fergus Daly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9c515b79-42e2-5a9b-1996-9281f3c2b0e8@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).