Package Name: mupdf
FAS name of maintainer: mjg
Background: mupdf (https://www.mupdf.com/) is both a library/framework for building PDF tools, and a document viewer reference implementation. A while ago, it was switched to shared libraries. While the upstream (Artifex) maintains a release branch (currently 1.25.x), the first thing they commit after a release is typically an soname bump (without further code changes) and then develop on top of that (both on master and - for selected cherry-picks - on the release branch). This leaves us two choices: - Backport fixes to our "stable" (rel;eased) Fedora branches: this may or may not be possible; it invalidates CVE reports against specific (upstream) mupdf release numbers - Use upstreams backports from 1.25.x (currently): this bumps soname but keeps CVE reports "valid" - Use versions from the master branch: same as above Note that currently, F41 is at mupdf 1.24.6 (because 1.25 wasn't released in time) but - according to upstream - the 1.24.x branch will not receive further fixes.
Therefore I ask for an update policy exception for mupdf. I would use it more "progressively" early in a Fedora release cycle, more conservatively late in a cycle.
Dependent packages: zathura-pdf-mupdf depends on mupdf. zathura/girara already have an exception (https://pagure.io/fesco/issue/1255), and grating an exception would benefit that ecosystem because girara/zathura (from pwmt.org) typically release from one branch only. I regularly coordinate updates with @ankursinha already.
python-PyMuPDF depends on mupdf, is a leaf package and maintained by myself. It is typically developped against the latest mupdf by upstream (Artifex) and benefits from - sometimes strictly requires - an up-to-date mupdf.
qpdfview is a newer (leaf) package depending on mupdf. Typically, it merely needs a rebuild. While I don't have commit rights there, coordinating rebuilds in side-tags has worked so far.
Metadata Update from @ngompa: - Issue tagged with: updates policy exception
Seems reasonable to me for something this important. +1
+1
Just to make sure, this is a request for a permanent exception, not for a one-off?
Yes, the same as the existing one for girara/zathura (as I understand it). That is why I tried to describe how I would use the exception depending on the "phase" a released branch is in.
The concrete versions mentioned are the current ones as an example of the "why" (I suggest an exception) and "what" (it would affect currently).
Thanks for clarifying, I am +1 then.
After slightly more than a week, this is: APPROVED (+8, 0, 0)
Metadata Update from @zbyszek: - Issue tagged with: pending announcement
Thanks everyone!
Announced https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NLMBBH3FKTZBTMUI2AII2JU3TP5YAXKK/
Metadata Update from @fale: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.