Texlive packaging (Was: A proposal for Fedora updates)

Jason L Tibbitts III tibbs at math.uh.edu
Fri Mar 27 16:49:19 UTC 2015


>>>>> "KL" == Kalev Lember <kalevlember at gmail.com> writes:

KL> If texlive packaging is causing issues with update pushes, could
KL> maybe ask the texlive maintainers to rework the packaging?

The texlive packaging is basically the way they were required to do it
way back when.  It used to be just a big ol' "texlive" package with only
a few subpackages that bundled up countless different upstream
packages.  Now it's a big ol' texlive srpm that bundles countless
different upstreams, but then splits each of those upstreams into a
subpackage.  A better way from a packaging standpoint, but not the
happiest outcome for our infrastructure folks.

And in a lot of ways it's similar to how Perl works, where there's a big
"distribution" that contains some stuff, and a bunch of collected
packages which are also available from separate upstreams.  However,
imagine how much the world would hurt if we just had one SRPM for CPAN
with thousands of subpackages.

What texlive needs now is to have a bunch of the packages split out.
They all have separate upstream tarballs and such and most don't change,
well, ever.  But that means a thousand package reviews.  So, fun.  And
every time you split one out.... you have to re-rev the entire texlive
world.

Even if we split out the largest, uhh, 50 texlive components, that would
still make only a tiny dent in the number of packages that would have to
be mashed when the main texlive package updates.

And from what I've seen, most texlive updaates aren't made due to
changes in some subsidiary texlive package, but becuase of structural
changes to the main texlive package.  And I'm not sure if that would
also require bumping the subsidiary packages.

But, sure, if someone cares about texlive, try to split out one or two
of the major packages.  See how it works and if it helps.  (Though one
package can't really help measurably; you'd have to do a hundred.)  You
can always merge them back in later if it turns out to be a horrible
idea.

 - J<


More information about the devel mailing list