TeX Live 2008/9 packaging and you

[Josh Boyer]

On Tue, Jun 02, 2009 at 01:27:26PM +0200, Jindrich Novy wrote:
>Hi all,
>
>sorry for long mail. I thought it's a good idea to catch up with you
>guys before I update to the new TeX Live in rawhide and discuss possible
>problems. To make really long story short, the new TeX Live comes with
>a huge set of subpackages (about 4000) so what I want to ask you if it
>will just slow down yum and general updating terribly or is it
>generally acceptable? (considering the metadata size growth?)

Thanks for the heads up.  I've also CC'd Seth for comments on potential
yum/repodata issues.

>For more details please read this (to-be) announcement:
>
>I finally manage to package the whole TeX Live 2008 distribution
>including binaries coming from the actual 2009 TeX Live development tree:
>http://koji.fedoraproject.org/koji/taskinfo?taskID=1382525
>
>Not only that it uses the latest rpm features such as:
>https://fedoraproject.org/wiki/Features/NoarchSubpackages
>New version texlive-2008 (to be in f12):
>* one single texlive package generating 3944 subpackages / 1065 MiB
>* spec file automagically generated from upstream metadata with
>  http://people.redhat.com/jnovy/files/tl2008/tl2rpm.c
>* upstream collections/packages are separate source tarballs
>  (one could update one small source tarball if a particular style
>  needs update and doesn't need to repack the whole single tarball or
>  patch it)
>* new texlive is maximally scalable depending on which features are
>  needed:
>  - basic installation needs only 12 MiB of packages to be downloaded!
>  - essential features such as pdflatex is supported in this basic
>    scheme
>* it is a full (not truncated or otherwise crippled) version of TeX
>  Live

So while I think flexibility is good, having almost 4000 subpackages seems
a bit excessive.  Is the split done for licensing reasons alone?  If so, could
we make larger groups by license or even just a single 'texlive-misc'
subpackage?

>From a rel-eng point of view, we have to sign all RPMs, subpackage or not.  So
when we get around to signing texlive, we'd need to now sign ~4000 packages.
That will add a significant amount of time to signing.

There is also the updates route to consider.  I'm not sure if bodhi is up to
handling an update with that many RPMs involved.  It may well be, but it would
need testing, which also brings up the signing issue since we sign updates too.

I'm sure others have questions as well.

josh