[tex-live] Stable vs. Unstable/Testing Update Repositories?
zdenek.wagner at gmail.com
Wed Feb 24 14:35:46 CET 2010
2010/2/24 Victor Ivrii <vivrii at gmail.com>:
> 2010/2/24 Zdenek Wagner <zdenek.wagner at gmail.com>:
>> 2010/2/24 C.M. Connelly <cmc at math.hmc.edu>:
>>> The beamer issue is just an example of the problems that can
>>> happen when you're dumping brand-new untested code into a update
>>> stream that's easily accessed by naive users.
>> Wrong! As turned out, the geometry package was tested and bug free.
> A bit too strong statement: let say "bugs were not found so far".
>> It just turned on the beamer bug that was there unnoticed for a long
> I am a bit uneasy with statements "people on deadlines should not
> update". There are some people who rely upon some big server
> administrated by sysadmin and at any given moment someone is on
> deadline. This is exactly the reason why system administrators in our
> dept maintain teTeX and allowed me to maintain TL. At least they know
> that they "did not changed nothing" when one of my esteemed colleagues
> screaming bloody murder requires explanations why some file which
> worked for the last 200 years stopped working (in 99.999% cases they
> made "minor" changes). So sysadmins want some assurance.
There is a difference between public repository run by volunteers and
professional enterprise sysadmin. Some time ago I developed LaTeX
package for a bank and it had to be verified by their sysadmin. The
employees can only use verified software. Thus they can use MiKTeX,
because it is verified by their sysadmin, but not TeX Live. Any
organization could block CTAN in the firewall, the sysadmin will make
a mirror of TL and if the sysadmin considers it stable, the local
mirror will be made available to employees.
> May be limited rollback feature would be helpful? For example keep
> previous versions of some major packages?
> Just thought
> Victor Ivrii, Professor, Department of Mathematics, University of Toronto
More information about the tex-live