# How to tell people why packages become deprecated and shouldn't be used anymore?

I'm working with LaTeX for a while now. Writing more and more documents I've learned that there are packages that should not be used or got replaced by others.

Looking into files my friends or students wrote I read those deprecated ever and ever again. I always tell them not to use them because there are better ones. Then they're asking me, why not update the old ones instead of writing new ones.

I wonder if there is any simply explanation, convincing them to write better code and use packages that are up to date.

-
Sometimes is better to build a new house with new materials and technologies instead of rebuild the old ones. –  Sigur Jan 24 '13 at 12:24
Potentially related is an answer Jim Hefferon provided (tex.stackexchange.com/a/94866/10038) about CTAN and guidance on the quality of a package. –  StrongBad Jan 24 '13 at 14:36

A major motivation for the design of TeX originally and also of LaTeX is document stability, you should be able to get a 20 year old LaTeX document and still process it. To get absolute guaranteed stability you need to archive the whole system executables, fonts, etc, but for the vast majority of cases that is not necessary and an old LaTeX document will run without change on a new system.

You see this in packages like fixltx2e which is distributed as part of the base LaTeX distribution. It implements a bunch of unrelated usability improvements to LaTeX which would be just directly incorporated into the code were it not for the compatibility requirements.

Note there is no such thing as a compatible change in a system like LaTeX that exposes its implementation at the user level. If you make any change to any command, some document somewhere will break. If you just add \relax or remove a spurious {} group or add a % to the end of a line in a place where space token can not do any harm, the operational behaviour of the modified command may be identical, but someone somewhere, will be using patch package (or just direct manipulation with delimited arguments) that is patching that command in a way that assumed the third token in its definition is \halign (or whatever) and the patch fails if that becomes the fourth token. Or perhaps the document is using \checkcommand and intentionally throws an error if the original command changes in any way.

So often when things change it is better to change the package name and put things in a new package, even if you are the maintainer of the original package and so could make the update in place. This means that old documents are unchanged. It does mean you have to at least partially support two versions of the code forever though.

Sometimes packages get effectively replaced by other people. enumerate and color for example are part of the core LaTeX distribution. You may see answers on this site suggesting they are replaced by say enumitem and xcolor but those packages are contributed extensions not part of the core release. That is a less important distinction than it used to be now most people use a tex distribution such as texlive or miktex as that handles package updating in a consistent manner whatever the original source. The names of those packages are different partly because they have different authors and are maintained separately, but as noted above even if the same maintainer were involved probably new packages would be called for so that the old interfaces remained the same.

Even if the command structure is identical, updating a package can be difficult, there are some reported instances of longtable making an allegedly suboptimal page breaking choice. Code to modify the decision making could be added but not without changing the page breaking in many existing documents which isn't really acceptable. Even if a new version is better in some way, if an existing document has forced page breaks to overcome a limitation in the old algorithm then the page breaking changes, a document could easily be left with pages that are empty or just with a couple of rows of a table. (In that case probably a package option to opt-in to the new features might be the thing to do.)

A couple of times I have tried to force a package deprecation by asking ctan maintains to remove the package from distribution. It doesn't really work: if you have a document archive of thousands of historical documents you don't really want to be going through them all to see if they use the old deprecated package and updating them to use the new one. It is simpler (and perfectly reasonable) just to complain and get the package put back (or to maintain a local copy of it).

-
Excellent answer, but I guess many people would like a TL;DR section. It could be something like: Document stability: you should be able to get a 20 year old LaTeX document and still process it –  moose Feb 5 '13 at 15:02

TeX has been around from quite some time now and the number of documents built over time is, well, rather large. Some of these older documents relied on functionality built in these obsolete packages. When creating a new package that reproduce the functionality of an older one, the choice is then whether you can make it backward compatible or not (same commands, exact same output,...). This is not always possible or desirable. The solution becomes then to leave to old package as is for backward compatibility reasons and build a new one that should preferably be used for newer documents.

Another reason why parallel development of packages can occur is when a new package is created for a (slightly) different reason, but with new features added, starts doing things better and therefore becomes the de facto package for a specific function, rendering the old one obsolete.

-

A very good resource to learn which packages are obsolete is l2tabu – Ob­so­lete pack­ages and com­mands (German original version) or l2tabu in Englisch (Thanks @ari-brodsky) which shows which packages should not used any more and gives alternativies.

I suggest to tell all your students to check this document before and while writing own documents, especially when they are using code of someone else ...

-
l2tabu is a great piece of paper. But it only shows which packages are deprecated and not why. But you are right this is one of the pdfs I suggested to my students. –  Rico Jan 24 '13 at 14:39
@Rico: Well, for example in chapter 2.2.8 natdin.bst vs. dinat.bst you can read that there is no more maintaining for dinat.bst. So sometimes you can find the reason why to change the package. It is a good starting point. And a look into the package documentation often explaines that the old package <name> is obsolet or ... –  Kurt Jan 24 '13 at 14:52

One aspect not covered in the other answers so far is the license most packages come with. It is the LaTeX project public license (LPPL). Currently, we are at version 1.3c. Older versions of that license explicitly required that new packages derived from older ones get new names, and must not carry files with the same name as the old package. The exception was that if you are the maintainer of a package, you could update your package. Even the current version of the LPPL requires the distinction between the old package, and the derived package to enable users of your derived package to obtain the old package. The LPPL therefore stands out somewhat from other Free Software licenses in that it cares so much about the old package that is derived from, and by codifying the role of a maintainer in the license itself. The whole reason for that is of course to keep old documents TeXable as-is, which David Carlisle laid out beautifully in his answer.

However, this can lead to the creation of new packages in situations where it is actually not needed, or even a nuisance. To give an example, suppose somewhat wrote a package to space out and underline text, and calls it soul. This package does not support UTF8 text, because at the time it was written, this was not so important. Some years later, someone writes a patch for soul to handle also some UTF8, plus some minor bugfixes. What should happen now? In other free software communities, say GNOME or KDE, the patch would be applied to soul, regardless of whether a maintainer acknowledges that, or can be found to aquire her acknowledgement. Heck, in those communities sometimes key figures can push through patches sidestepping a protesting maintainer of some module! Not so in the LaTeX world, as the license forbids that. The LPPL describes a lengthy process to obtain maintainership of a seeminly orphaned package, but how much easier it is to upload your patched version of soul to CTAN under a new name, say soulutf8. Alas, we have another deprecated package, and a successor package.

While this explains the existence of some packages on CTAN, by no means I would like to suggest that this is the, or a main reason for the rewrite-over-update nature your students observed. But it plays into it. If you want to convince them to use the newer packages, tell them there are just "higher versions" of the older packages. And everyone loves higher version numbers.

-
I wouldn't overplay the license issue. For example, for biblatex there was an issue the original code is 'author-maintained' (LPPL1.3c), so when Philip Lehman went off the radar a 'new' project was needed. However, as this is functional identical to his code, the 'new' project is still called biblatex and CTAN have been happy to take the code. (His code is still available from SourceForge.) –  Joseph Wright Jan 25 '13 at 8:09
@JosephWright Do you think I overplayed it? I was hoping that my last paragraph prevented that. –  mafp Jan 25 '13 at 8:46

"Every LATEX user faces the compatibility nightmare, one day or another. With such great intercession capability at hand (LATEX code being able to redefine itself at will – no code protection is offered whatsoever), a time comes inevitably when the compilation of a document fails, due to a class/style conflict. In an ideal world, class/style conflicts should only be a concern for package maintainers, not end users of LATEX. Unfortunately, the world is real, not ideal, and end-user document compilation does break. The situation is close to anarchy." - Didier Verna (article, presentation)

There are too many needless code/package forks in LaTeX. It is truly a nightmare. You can't protect your internal or user commands. \def is always an earthquake, and a developer is powerless against a user who finds \newcommand or \@ifdefinable incovenient, or thinks they're unimportant. But lest we forget: Knuth insists he didn't mean TeX to be popular with developers; he only wanted a simple system for his secretary's use. I don't know if LuaTeX or any engine offers code protection and/or automatic prefixing of all a package's commands with (perhaps a shortened form of) the package's name.

Didier is right in arguing that TeX, being merely a macro expansion language, usually offers no programming style and, sadly, doesn't insist on one.

-