[tex-live] Stable vs. Unstable/Testing Update Repositories?
George N. White III
gnwiii at gmail.com
Wed Feb 24 12:42:40 CET 2010
On Wed, Feb 24, 2010 at 7:31 AM, T T <t34www at googlemail.com> wrote:
> On 24 February 2010 00:12, C.M. Connelly <cmc at math.hmc.edu> wrote:
>> "KB" == Karl Berry <karl at freefriends.org>
>> KB> 1) People on deadlines shouldn't update.
>> Of course not, but updating is a great way to procrastinate, plus
>> it gives you the warm glow of having all the latest and greatest
>> features. Saying that people should use common sense doesn't
>> really help us, as all humans do dumb things sometimes, especially
>> when it's made easy for us.
> I disagree with your assessment here. Even well tested updates can
> sometimes break your system. When being on a tight deadline I usually
> don't update anything, including the OS. The rule "if it ain't broken
> ..." applies is such situations.
Many large organizations force-feed security updates -- breaking some
end-user app is seen as less risky than leaving systems vunerable to
crackers. These "large-organizations" are also concerned with security
of home systems of their workers -- if you work for a large organization
there are people who want to know everything about you, including what
is on your home computer.
>> KB> The only combination of packages that is or can be tested
>> KB> is the one that ships as the yearly release. Personally,
>> KB> I keep an installation of that on my machine, and never
>> KB> update it.
>> That's a reasonable policy, but it's not the policy that's
>> suggested by the easy access to the updating features (which are
>> also used for installing additional packages) in the current TeX
>> Live. If updating is something that only the most hardcore,
>> living-on-the-edge folks should be doing, it should be hard(er) to
> The update system is not intended for hardcore types only. Although
> updates can occasionally result in breakage, most problems are
> addressed within days and hot fixes for the critical ones are often
> available within hours. I think this is quite a reasonable and
> workable time frame in most cases. People requiring a stable system at
> all times should update rarely or make regular backups.
> What we could do to improve the situation somewhat is to set the
> autobackup option in tlmgr as default.
>> KB> 2) There is no feasible way for anyone involved (authors,
>> KB> CTAN, TL) to know what a given update breaks and what
>> KB> doesn't. So there's no feasible way to have branches (in
>> KB> addition, it would be a huge amount of work and a huge
>> KB> additional complication).
>> The same argument could be made about any of the Linux
>> distributions, which have thousands of potentially interacting
>> packages from hundreds of upstream developers. Yet they manage by
>> implementing some system to handle the testing stage -- Debian has
>> The same options could be used for TeX Live. There could be a
>> time-based progression, where new packages come in from CTAN and
>> are added to a bleeding-edge TL repo for people to play with, and
>> after some amount of time, those packages would qualify to be
>> moved into the main TL repo that's considered safe to update from.
>> New versions of a package reset the clock. Adding some active
>> testing would make that system even safer, of course, but would
>> make things more complex.
>> An even easier (and arguably better) option is to simply have a
>> stable release repository, that only gets bugfixes or well-tested
>> feature changes, and a second development repository where the
>> newest stuff comes directly in from CTAN, and publicize the stable
>> repositories. An added advantage here is that you can continue to
>> maintain that release for as long as you want, and even keep it
>> around for people who aren't ready to update to the next year's
> While I agree with what you propose in general, our resources are
> already spread quite thin. Besides the lack of man-power and technical
> hurdles there are also hosting problems -- TL is quite big and that
> alone can preclude maintenance of multiple concurrent repositories.
> That being said I will discuss with the rest of the team some ideas
> and see if there is anything that we could do (but don't hold your
TL is not big by today's standards. A snapshot of the TL archive
directory can easily be stored on a PC too old to handle Windows
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the tex-live