Bug 2272526

Summary:	Since spec file was "modernized", consumers unexpectedly cannot use libraries in /usr/local/lib
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	fedora-messaging	Assignee:	Aurelien Bompard <aurelien>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	39	CC:	aurelien, gui1ty, infra-sig
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	AcceptedFreezeException
Fixed In Version:	fedora-messaging-3.5.0-2.fc40 fedora-messaging-3.5.0-2.fc39	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-04-10 03:12:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2187795

Description Adam Williamson 2024-04-01 18:22:25 UTC

Back in December, the spec file was "modernized": https://src.fedoraproject.org/rpms/fedora-messaging/c/8998b22ef8c5dfa987a33df04a8d84bb729e4e3e?branch=rawhide

That commit is now on f39, f40 and rawhide branches.

Builds with these changes produce a /usr/bin/fedora-messaging with this hashbang:

#! /usr/bin/python3 -sP

builds done before the modernization had this hashbang:

#!/usr/bin/python3

This has a significant effect:

$ python3
>>> import sys; print(sys.path)
['', '/usr/lib64/python312.zip', '/usr/lib64/python3.12', '/usr/lib64/python3.12/lib-dynload', '/usr/local/lib/python3.12/site-packages', '/usr/lib64/python3.12/site-packages', '/usr/lib/python3.12/site-packages']

but:

$ python3 -sP
>>> import sys; print(sys.path)
['/usr/lib64/python312.zip', '/usr/lib64/python3.12', '/usr/lib64/python3.12/lib-dynload', '/usr/lib64/python3.12/site-packages', '/usr/lib/python3.12/site-packages']

this means that, after update to a newer build of fedora-messaging, consumers suddenly cannot use libraries in /usr/local/lib(64) any more. It's the -s that changes this part, not the -P; it seems that -P drops the empty string from the start of the list, -s drops the /usr/local subdirectories.

This broke a bunch of important production Fedora consumers that run on openqa01, because they use the 'fedora_openqa' library that I maintain, and because it often needs updating and sometimes I need to use a different branch for testing, I don't package it; I just install it from a source checkout with `python -m pip install .`, which puts it in /usr/local/lib.

I guess we may think this is a desired change, but it was certainly unexpected for me in a stable update to Fedora 39, and it was not communicated in the package changelog or the update description. It's also not in line with how things conventionally work on Fedora; it has always been that case that libraries in /usr/local/lib *are* used by default.

Comment 1 Sandro 2024-04-01 19:11:21 UTC

I suppose this is an entirely unintended side effect of the spec file modernization. The `-s` flag has been a default for a long time. It's documented in the 201x-era Python packaging guidelines[1]. The `-P` flag was added in F37 according to the Python Safe Path change proposal[2].

This doesn't solve the issue at hand, but it gives some background to where this is coming from. I guess using a library from /usr/local/lib is hard to account for or know about when testing this change. For the majority of people the shebang change will go unnoticed.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/#_macros
[2] https://fedoraproject.org/wiki/Changes/PythonSafePath

Comment 2 Adam Williamson 2024-04-01 21:30:10 UTC

Ooh, yeah, I didn't realize that.

So...well, I can see the point, of course. For things that are "part of the system" I can see the desirability of not pulling in "non-system" libraries.

But it doesn't seem a good fit for something like fedora-messaging consumers, which are *intentionally* a pluggable/expandable mechanism.

Comment 3 Aurelien Bompard 2024-04-04 07:15:10 UTC

Sorry about this mess, I've blindly applied the packaging guidelines and didn't think it would cause this. I'll remove the "-s" from the shebangs.

Comment 4 Fedora Update System 2024-04-04 09:14:00 UTC

FEDORA-2024-a8e2a0fc1b (fedora-messaging-3.5.0-2.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a8e2a0fc1b

Comment 5 Fedora Update System 2024-04-04 09:15:17 UTC

FEDORA-2024-f78a821bf2 (fedora-messaging-3.5.0-2.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-f78a821bf2

Comment 6 Fedora Update System 2024-04-05 01:40:44 UTC

FEDORA-2024-f78a821bf2 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f78a821bf2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f78a821bf2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Adam Williamson 2024-04-05 01:45:37 UTC

I'm actually gonna suggest we give this a Final FE, just in case it bites anyone with a custom message consumer who decides to upgrade a bit early. Seems like the kinda thing that might cause needless stress.

Comment 8 Fedora Update System 2024-04-05 02:03:42 UTC

FEDORA-2024-a8e2a0fc1b has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-a8e2a0fc1b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-a8e2a0fc1b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Adam Williamson 2024-04-06 17:34:24 UTC

+3 in https://pagure.io/fedora-qa/blocker-review/issue/1562 , marking accepted.

Comment 10 Fedora Update System 2024-04-10 03:12:43 UTC

FEDORA-2024-f78a821bf2 (fedora-messaging-3.5.0-2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 11 Fedora Update System 2024-04-13 01:13:28 UTC

FEDORA-2024-a8e2a0fc1b (fedora-messaging-3.5.0-2.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.