Bug 1926533 - Postinstall scripts are failable, fail during KDE netinst (due to dependency loop most likely)
Summary: Postinstall scripts are failable, fail during KDE netinst (due to dependency ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-fonts
Version: 34
Hardware: All
OS: All
unspecified
urgent
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-09 01:08 UTC by Adam Williamson
Modified: 2022-05-14 01:25 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-14 01:25:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2021-02-09 01:08:54 UTC
In current Fedora Rawhide, KDE network installs fail with a scriptlet error in an xorg-x11-fonts subpackage:

16:36:01,304 INF dnf.rpm: mkfontscale: error while loading shared libraries: libfreetype.so.6: cannot open shared object file: No such file or directory
warning: %post(xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch) scriptlet failed, exit status 127

16:36:01,310 ERR dnf.rpm: Error in POSTIN scriptlet in rpm package xorg-x11-fonts-ISO8859-1-100dpi

Dependencies should be in place, AFAICT: xorg-x11-fonts subpackages require 'mkfontdir', which is in the same package as mkfontscale (xorg-x11-font-utils) and that package requires libfreetype.so.6. What's likely happening is a dependency loop that dnf has to break somehow. This isn't uncommon on initial install, something like A requires B requires C requires A, and in order to do anything, dnf has to pick *some* dependency to disregard. Probably because of some loop like this, it's ordering install of xorg-x11-fonts-ISO8859-1-100dpi before install of freetype, and so its %post script fails.

We could look for and try to fix that loop, but note the packaging guidelines state:

"All scriptlets MUST exit with the zero exit status. Because RPM in its default configuration does not execute shell scriptlets with the -e argument to the shell, excluding explicit exit calls (frowned upon with a non-zero argument!), the exit status of the last command in a scriptlet determines its exit status. Most commands in the snippets in this document have a “|| :” appended to them, which is a generic trick to force the zero exit status for those commands whether they worked or not. Usually the most important bit is to apply this to the last command executed in a scriptlet, or to add a separate command such as plain “:” or “exit 0” as the last one in a scriptlet. Note that depending on the case, other error checking/prevention measures may be more appropriate.

Non-zero exit codes from scriptlets can break installs/upgrades/erases such that no further actions will be taken for that package in a transaction (see Ordering), which may for example prevent an old version of a package from being erased on upgrades, leaving behind duplicate rpmdb entries and possibly stale, unowned files on the filesystem. There are some cases where letting the transaction to proceed when some things in scriptlets failed may result in partially broken setup. It is however often limited to that package only whereas letting a transaction to proceed with some packages dropped out on the fly is more likely to result in broader system wide problems."

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax

basically, by policy scriptlets should be written to return 0 even if they don't work. These scriptlets aren't respecting that. Given that not running mkfontdir likely doesn't have any calamitous consequences, I think it would make sense to go with the guidelines and amend all the scriptlets to add `|| :` at the end (which will cause them to exit 0 even if the command failed).

Comment 1 Ben Cotton 2021-02-09 16:10:25 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 2 Adam Williamson 2021-02-23 01:48:40 UTC
https://bodhi.fedoraproject.org/updates/FEDORA-2021-2db3037308 should fix this, I got it in just under the freeze wire. Hopefully KDE netinsts and MATE image composes (which were also affected by this) should be fixed in next compose.

Comment 3 Ben Cotton 2022-05-12 16:59:06 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 4 Adam Williamson 2022-05-14 01:25:09 UTC
I think this was fixed OK.


Note You need to log in before you can comment on or make changes to this bug.