Texlive packaging

[Paulo César Pereira de Andrade]

2015-03-28 16:40 GMT-03:00 Florian Weimer <fw at deneb.enyo.de>:
> * Matthew Miller:
>
>> On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
>>> Actually "machine generated" isn't per se bad  ... it saves a lot of
>>> effort and should be done more (for other packages too where
>>> possible).
>>> Why waste man power for something that can be automated?
>>>
>>> As for tex ... we could have a srpm for each one (machine generated
>>> there is no reason it has to be one srpm) would also mean that only
>>> the packages where something changes end up getting updated.
>>
>> Right, as I understand it, the gigantic single SRPM is to avoid the
>> normal requirement that each individual package have its own manual
>> review. For thousands of packages, that's quite a burden.
>
> TeXLive isn't just an installer for random versions of CTAN packages,
> right?  They do make releases.  So the bundling is not unlike what
> happens with, say, OpenJDK releases, where it is still not unheard of
> to mix-and-match Hotspot from here and the class libraries from there,
> and yet there is just one SRPM per release.

  One can update the binaries and "noarch" yearly. Usually most important
would be to fetch bugfixes and security fixes from the "year" branch
See https://www.tug.org/svn/texlive/branches/
The noarch could be fetched from ftp://tug.org/texlive/historic/

  It is more about keeping up to date or not with upstream, e.g. the
2k+ subpackages all handled by upstream, or doing it yourself, I am
afraid not an easy task, creating a spec to list files from a > 1G
.xz file.

> Debian has a middle-ground, with slightly more than 100 binary
> packages, built from four source packages (as far as I can see).

  Technically, Debian also does not have a lot of packages because
they as well have quite a lot of bureaucracy to create packages,
not a bad thing, of course.

  See last paragraph of http://tug.org/pipermail/tldistro/2011q4/000162.html

Thanks,
Paulo