public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
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

  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).