MC> Now, the question is how to build just one subpackage (or any MC> required other subpackages) from the monstrosity which the current MC> texlive? Anybody any suggestions? Just package it separately. They should all have proper upstream tarballs, and there's no reason not to just make individual packages if that's what you need. And, hey, while you're at it, stick them in rawhide and make the texlive package not generate them at all. Anything that gets split out of texlive into proper packages is a win. - J<

On Wed, Apr 8, 2015 at 12:30 AM, Matěj Cepl <mcepl(a)cepl.eu&gt; wrote: One reason I'm building my OSJourno Docker images on Fedora and not the more popular and theoretically more stable CentOS is that EPEL doesn't have a few LaTeX packages I need. Sometime when I run out of more pressing things to fix, I'm going to try texlive-texliveonfly to see if it can find and install missing LaTeX packages. Seriously, texlive is huge - if you install *everything* IIRC you have something like 4 GB just for texlive! So there's every reason to want to install a minimal texlive and install packages on an as-needed basis. And I'm curious why there are texlive packages in Fedora that aren't in EPEL - I assume it's a human or machine resource constraint. -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-jou... Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.

On 04/08/2015 03:06 AM, Jason L Tibbitts III wrote: +1 That's similar to the way we had split perl into pieces years ago. Ralf

Once upon a time, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; said: Each time a small piece is sliced out of the giant package, the giant package must also be rebuilt to exclude that piece. That's a lot of churn on a giant package with a massive number of subpackages; it would be better to batch up pulling out lots of pieces at once. -- Chris Adams <linux(a)cmadams.net&gt;

On 8 April 2015 at 19:40, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote: I look at tl2pm and think "it would be fairly easy to patch that to spit out 4000 and something spec files rather than one 16 MB one". The unresolved issues are whether doing that would invalidate the previous license audit (it shouldn't really), and whether FESCO would grant a package review exception for those packages.

On 04/08/2015 12:46 PM, Jonathan Underwood wrote: This may be worth pursuing. Or rewriting it in python :) While we're at it I think we need to revisit the version numbers. Currently we have things like: %global tl_version 2014 %global tl_rel 11 %global tl_release %{tl_rel}.%{source_date}%{?dist} %global tl_noarch_release %{tl_rel}%{?dist} %package aastex Provides: tex-aastex = %{tl_version} Version: svn15878.5.2 Release: %{tl_noarch_release}.1 Provides: tex(aastex.cls) = %{tl_version} Provides: tex(aastex.sty) = %{tl_version} This doesn't appear to comply with https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages which I believe would imply: Version: 5.2 Release: #.svn15878 The Provides version seems fairly arbitrary, but perhaps there is a reason for it. I've just spent the better part of two days packaging up a couple missing EL7 texlive packages for internal use, would be nice to get this fixed at the distro level. Also, it is completely maddening that upstream does not appear to provide anything but the most current tarball for packages, e.g.: Source0100: ftp://ftp.ctex.org/mirrors/CTAN/systems/texlive/tlnet/archive/aastex.tar.xz unless anyone is aware of anything else? Perhaps we should be building from source: https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/source/latex/aastex/ or ctan? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com