Fedora 18's TexLive packaging failure

April 8, 2013

Fedora 18's texlive package has a problem. Actually it has at least two problems, one of which makes it our problem. The first problem is that other packages require bits of it to be installed; this is the only reason I have any texlive packages installed. The second problem is that the TexLive package maintainers have chosen to split it up into a truly absurd number of sub-packages. Many of these sub-packages are small, only a few kilobytes (some are below a kilobyte), and some of them are actually empty.

(Other fun things include multiple copies of the GPL, duplicated between various sub-packages. For some packages, the GPL text is the largest single file. Also, some of those empty packages are explicit dependencies of other packages. Why? Who knows.)

Another issue seems to be that texlive's internal dependencies keep creeping around in a way that expands the number of texlive packages installed on your machine over time. My work machine crept up to over a thousand texlive packages, amounting to a fifth of all packages installed on it, and I've seen texlive package updates require additional texlive packages.

This isn't just a problem of massive clutter and its discontents, or of stupid packaging gone absurd. Various yum operations, such as installing package updates, take an amount of time proportional to the amount of packages (no matter how small or empty the package is). Having hundreds of little texlive packages installed thus slows them down drastically; the straw that broke the camel's back on my work machine was a package update that took more than an hour because it was updating over a thousand texlive packages. This elevates texlive's absurd number of sub-packages from merely a bad idea to actively harmful (both because long package update times annoy people and because they encourage people not to update things at all).

I don't know how Fedora allowed things to reach this level of absurdity. But it is absurd and stupid. I've filed a bug about the package count (I didn't discover the other absurdities until now) but to be honest I don't expect anything to change.

(By the way, having this many texlive packages doesn't help people in the least if they want a minimal texlive installation. There are so many packages and they are so absurdly named that I defy anyone who is not deeply immersed in TexLive arcana to figure out what packages they need and what packages they don't.)

I'm sure that the TexLive packagers have some reason for doing all of this; people are rarely crazy. It's just that their reason is a bad one because it has led them into a maze of absurdities. To me this smells of a vastly over-engineered solution, perhaps one put together in the nominal name of efficiency. If so, it has backfired (as these things often do); in a quest for efficiency it has instead created great inefficiency.


Comments on this page:

From 99.236.92.95 at 2013-04-09 06:44:17:

Looks like a great deal of research and thought was put into the response.

I agree with you - that's ridiculous.

I especially love having to install texlive packages on servers because some documentation I'll never read on the system "needs" them.

-- Mike

From 206.248.171.116 at 2013-04-09 09:02:41:

Have you looked at the Texlive source RPM? There are 5000 subpackages and a 150 MB spec file, with a compressed SRPM size of 1.5G. It's the package-from-hell for the buildsystems.

I think the only reason this doesn't contravene the packaging guidelines is that we never thought anyone in their right mind would think of doing this.

-Chris Tyler

From 138.246.84.69 at 2013-04-09 09:38:57:

For comparision: Arch Live packages TeXLive into 20 packages (by category), a simple install is 2 packages (360mb). A full install is about 1Gb...

From 108.23.63.163 at 2013-04-09 12:43:22:

The TeX{, Live} packages for most distros are always sufficiently old that on the Linux side we just install TeX Live from upstream. It has its own package management system (although we're installing it on a server share, so we install everything anyway), and it's updated pretty frequently.

On our Mac clients, we install the MacTeX package, which includes everything in TeX Live plus some Mac-specific software. MacTeX is updated occasionally, and updating it on the clients is just a matter of pushing the new package.

(You can update TeX Live on the Macs in the same way you do on the server, but I only do that on my own machine.)

On Debian, the TeX Live packages are maintained by one of the TeX Live developers. There are still quite a few packages, but I think they're split up in a saner way than on Fedora (i.e., there are sensible groupings of LaTeX packages, rather than separate OS packages for each LaTeX package). I know (from having been part of the teTeX packaging team) that the Debian packages were split up because people objected to having to install huge packages just to use some basic functionality (e.g., in other packages). Because of Debian's release cycle, they're just as likely to be out of date, of course.

-- Claire

Written on 08 April 2013.
« Why ZFS still needs an equivalent of fsck
Some important things about OpenBSD PF's max-* options »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Apr 8 21:44:52 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.