F45 Change Proposal: TeXLive2025 [Self-Contained]

TeXLive2025

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

TeX Live is intended to be a straightforward way to get up and running with the TeX document production system. It provides a comprehensive TeX system with binaries for most flavors of Unix, including GNU/Linux and macOS, and also Windows. It includes all the major TeX-related programs, macro packages, and fonts that are free software, including support for many languages around the world.

This change will update TeXLive in Fedora to 2025, and move to a modular packaging approach that allows for more fine grained upgrades and maintenance.

Owner :open_book:

Detailed Description :open_book:

The Fedora “texlive” package is the largest RPM spec file in Fedora. While it was broken into two packages (“texlive” and “texlive-base”) a few years ago, the “texlive” spec contained thousands of sources and was very difficult to maintain. Additionally, because all of the noarch components lived in a single SRPM, updating any component generated an update for all noarch texlive components.

With this change, we update to the latest version of TeXLive (2025) but we also move to a modularized packaging system, which splits the “texlive” SPEC into a set of collection and scheme packages, reflecting the categorization that TeXLive upstream defines. Each collection package will package the immediate component dependencies as subpackages.

This will require 50+ new package reviews.

Feedback :open_book:

The alternatives to this change are:

  • Just update the existing texlive/texlive-base files to TeXLive 2025. While possible, it is very difficult to get a single spec file updated. In 2023, this took me several months. This time, I chose to invest time in developing a modular approach instead. I also created a set of python tools to generate these collection/scheme spec files, which I plan to open source (but not package in Fedora because that’s just too meta).
  • Leave TeXLive at the 2023 revision. This is not ideal and not in keeping with Fedora’s “First” principle. Additionally, users have asked for the 2025 update.

Benefit to Fedora :open_book:

The modular packaging approach will make TeXLive easier to maintain and update in Fedora. It is my hope that other maintainers will feel more empowered to help maintain subsections of TeXLive that they care about, but even if not, it will be easier for me to maintain it. This approach will also lower the number of updates pushed to Fedora users with any parts of TeXLive installed.

TeXLive 2025 provides a few key advantages:

  • It generates PDF-1.7 format files by default
  • Scaling fonts to >= 2048pt now results in an error message, instead of (unhandled) arithmetic overflow or silent changing of the user’s value
  • Improvements to LuaTeX and pdfTeX
  • Many individual components have had updates since TeXLive 2025.

Scope :open_book:

  • Proposal owners:

50+ package reviews for the new modular set of texlive packages. These spec files, while sometimes long, are simple. None of them have %build sections, and their %install sections are 95% code copying, and 5% patching or file delete/move operations.

None of them depend on other Fedora package changes, though, we will recommend a change to emacs-auctex to better detect the current set of TeX provides.

With the exception of emacs-auctex, we do not anticipate any other developers will need to make changes. The goal is for any TeX documentation in other Fedora packages to continue to render and save without issue.

While a mass rebuild is not required, it has been beneficial in the past to identify bugs in TeXLive. Because the scope of TeXLive within Fedora is just generated documentation in TeX format, failures here are usually worked around by providing a pre-rendered document.

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:
    TeXLive provides a broad set of internationalization support, allowing people to work in their native languages. Keeping TeXLive current helps Fedora “Reach the World”.

Upgrade/compatibility impact :open_book:

Users may wish to delete their local cache in ~/.texlive2023. After upgrade, a new ~/.texlive2025 directory will be created and used.

Early Testing (Optional) :open_book:

How To Test :open_book:

The “texlive-base” package contains some local testing to ensure it is being built with a working TeXLive environment, and it also runs the full upstream test suite. No special hardware or data is needed to test. Expected outcome is that TeX documents render properly.

User Experience :open_book:

Users will get the latest version of the TeXLive components and system. Users will also get less TeXLive package updates from Fedora.

Dependencies :open_book:

Fedora packages with TeX-format documentation which render that documentation as part of the build process. No other changes outside of the TeXLive system are necessary for this change.

Contingency Plan :open_book:

Documentation :open_book:

Release Notes :open_book:

Last edited by @alking 2025-10-29T14:22:58Z

Last edited by @alking 2025-10-29T14:22:58Z

2 Likes

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

I strongly support this change.

The TeXLive version lag is very likely to be the exception to the Fedora claim of keeping things close to cutting edge. As the proposal acknowledges, the current edition is closing in on two years old; by contrast, TeXLive updates from CTAN happen almost daily.

One of the reasons that I moved my personal computers to Fedora several years ago was to avoid problems I’d encountered with Debian getting so far behind upstream over the life of an OS version.

In the end, I uninstalled all of the TeXLive packages from my system and installed TeXLive from CTAN. This gave me a fairly benign problem with Workstation as Evince depends on some small subset of TeXLive packages. It uninstalled with the TeXLive package removal. I went ahead and re-installed Evince and didn’t encounter any conflicts, at least that I’m aware of, after it installed some dependencies from the TeXLive package set coincident to my separate installation of CTAN TeXLive. I have since moved to Plasma to avoid this issue in the future.

I am also in favor. I’m happy to help with package reviews.

I agree that this is extremely valuable work, and I also plan to assist with package reviews.

Strongly in favor, and we cannot thank @spot enough for all his efforts to keep tex alive in Fedora!

Please let us know when you need testers or anything else (besides the obvious reviews).

Very much in favor! Thanks for doing this spot!

I have no experience with Fedora packaging, but I’m a Fedora user and an upstream TeX Live developer, and I’d be more than happy to help with implementing this.

TeX Live follows a rather bizarre versioning scheme, so as context for those unfamiliar with it:

  • Compiled binaries (and their corresponding sources) are only released once per TL version, so any installation of TL25 will always have the same version of pdftex, luatex, and similar.

    In the event of serious bugs or security issues, TL will update the binaries, but this is fairly rare, and any updates will be for bug fixes only, so they should always be safe to apply. And the biber and luametatex binaries are special and update throughout the year.

  • The TeX Live team itself only maintains the binaries and a few other infrastructure packages; everything else is handled independently. So TL is a lot like a Linux distribution in that its main role is packaging others’ code.

    TL pulls package updates from CTAN daily (I personally handle a bit less than 1% of these updates, and another maintainer handles all the rest); most days there are around 3–10 different packages with updates. TL contains around 5000 different packages, and some of these update multiple times per week while others haven’t been updated in 20 years.

    Packages can be both added and removed within a TL release.

  • About a week before a new TeX Live version is released, the current TL release gets frozen, and no more new (package) updates will ever be made available for it. As soon as the new TL version is released, package updates resume. So because of this, an installation of TL24 updated on the very last day is almost identical to the initial release of TL25.

  • TeX Live .isos and package updates are distributed through a decentralized system of mirrors that are supposed to update (at least) daily. The primary/authoritative is only accessible to other mirrors, but the ctan.math.utah.edu/tug.ctan.org mirror is the unofficial main secondary mirror. All packages and .isos are signed by the main TL GPG key.

  • TeX Live’s package manager fully-supports dependency management, but many package authors don’t provide dependency information. The TL maintainers can add dependency information to packages themselves (independently of package authors), but this is only done when someone tells us, since it’s too much work to go through every single package and figure out the dependencies.

  • Because of the above point plus some historical oddities, most TeX Live users install every single package, which is very different from how PyPi, CPAN, NPM, and every other ecosystem operates. Despite this, only installing specific packages is fully-supported by the TL developers.

So because of all this, “TeX Live 2025” isn’t really a single version. I’d recommend against just using the initial release (the only one available as a complete .iso file) because it’s outdated from the day that it is released.

One of the other TeX Live developers maintains a historic mirror of every TL package by date, so I’d recommend picking a specific (and as recent as possible) date for every Fedora release and using that for the duration of the release. That way, the set of packages will be stable while still being somewhat recent.

This seems like a reasonable compromise. There are ways users who encounter bugs can arrange to use current packages, but there may be cases where many users are affected, so a “bug-fix” package with selected newer CTAN packages may be needed.

On the spectrum of stability versus exposing newer stuff to a wide range of use cases, Fedora leans towards newer stuff, so stability is sometimes sacrificed. Fedora users who delay updating until just before support for the release ends, as well as the broader Linux community benefit from broad exposure of current linux packages to a wide range of use cases so isses are found before they make their way into other distros or the next Fedora release.

There are systems like the R where user developing or enhancing libraries want stability in R-markdown. Those who only need TeX for use wth R-markdown, there is the R-tinytex package that provides CTAN packages.

For years I have been installing both Linux distro and CTAN TeX, and using the Lmod package to adust the PATH in a command-line session, but I encounter younger users who are relucatant to use command-line tools. In recent years almost everytihing I need works in either version.

2 Likes

I installed a fresh version of TeXLive 2025 back in early August when I last did a clean installation of f42 Plasma Edition on a new laptop. I have seen periodic, although as you state, not daily, compilations of format files. That is, at least if I understand things correctly.

Here is a bit from the logfile for the last re-compile of pdflatex:

[Sat Sep 27 09:33:07 2025] command: fmtutil-sys --byfmt pdflatex-dev --no-error-if-no-engine=luametatex,luajithbtex,luajittex,mfluajit --status-file=/tmp/gho8XAAAl1/JifYVwRfQP
[Sat Sep 27 09:33:12 2025]   OK: pdflatex-dev.fmt/pdftex

Again, I may be interpreting these things incorrectly, but I’m seeing these kinds of log entries roughly once every week or ten days, or so. Of course, as you say, there are other updates along the way, which occur roughly daily.

I didn’t mean not to downplay how big of an effort supporting TeXLive is for the packager. Nor did I mean to neglect to recognize this and to thank him for putting in the work making that happen.

But I do think that any change to the packaging game plan that results in an easing of that load, and perhaps, enabling them to distribute the effort among a group of packagers, is a good one.

If there is a resource for non-packagers to review what needs to be done to do these reviews, I’d be happy to help with the reviews as well.

  • Yes, the format files will be recompiled locally whenever the underlying files update. The format files are a binary dump of the TeX interpreter after it’s loaded a bunch of TeX files, but when I said “binaries”, I meant “binary executables” (which are platform-specific and require a C compiler to generate), not the format files (which are platform-independent and only require a TeX engine to generate).

  • The -dev format files do indeed update weekly (or more often), but those are beta releases that are only useful if they’re up-to-date with upstream, so I don’t think that Fedora should ship those. The other format files usually only update monthly (or less)

1 Like

This change proposal has now been submitted to FESCo with ticket #3488 for voting.

To find out more, please visit our Changes Policy documentation.

This change has been approved by FESCo and will be included in Fedora Linux 45.
To find out more about how our changes policy works, please visit our docs site.

FESCo Issue: Making sure you're not a bot!