There’s been some recent discussion on the TeX Live mailing list about recording dependencies for (La)TeX packages. This is a good idea but means that package authors need to think about their dependency situation. So I thought a few words on this would be helpful, at least from the point of view of the most common case: LaTeX packages.

It’s pretty easy to accumulate \RequirePackage lines in your source, but if you are serious about giving a useful set of dependencies you need to know what each one is for. In many ways the rule is easy: require each package you use. What makes that more complicated is that you might use features which are available when you load package X but are actually provided by package Y. For example, if you load my siunitx package, it loads array so means that you can do for example


So how do you tell what your ‘real’ dependencies are? The usual rule is that you check the documentation: does it say that package X itself provides the features you use? In the case above, siunitx doesn’t document that syntax extension for tabular: it’s documented by array. So if you wrote a package that uses siunitx but also needs to use features from array you should


This means that even if at some future stage there’s a change in the internals of a package you load, things should still all work.

If you want to track down where stuff might be coming from, you can always \listfiles to get a full overview of your current package use (starting from a small example).

There are a few places were packages are so closely linked you might not have to list them both. The most obvious is TikZ/pgf: the two are different ‘layers’ of the same set up but are documented together, so if you load TikZ you can assume pgf. Of course, there is no harm in listing both!

New CTAN, new toys

Many readers will have been watching the updates to CTAN with interest. So far, we’ve seen a new layout to the site, with a promise of new ‘toys’. Some of these have now appeared at least in testing form, and can be accessed at

The biggest change is that you can now register an account, and use this to vote on packages. I’ve of course registered already, and taken a very quick look at the voting system. I notice that at the moment the system doesn’t spot that I’m the author of some packages, so can vote on them! Of course, I’m not going to do that, and if there are lots of people voting it won’t matter.

A new upload system for CTAN

The CTAN Team are currently testing a new upload system. There are several things going on with this new approach. First, if your material has been uploaded before then you can find it on the list of known packages, so various pieces of information are automatically available. Secondly, you can see the meta-data about your upload, for example the short README-like text you see in the CTAN database. That means you can correct/add to the entry, and hopefully makes Robin Fairbairns life a little less busy!

The default page for uploads includes a list of all of the packages that CTAN contains (more or less: I’ve not checked the entire list!). There’s also a page you can use if you know the package name for your upload. I like that one, perhaps as I know the names of all of my packages and the aforementioned list is rather long!

Cross-platform working

As many people will know, the CTAN team have come up with the idea of having TDS-ready zip files for packages. The idea is that you can just download the zip into your local TeX directory, unzip it and run texhash, with no TeX-based unpacking or document compilation.

That’s all fine when it works, but I’ve recently had a bit of trouble making zips at my end. My favoured tool for doing that has tended to be 7-Zip. However, it was pointed out to me last week that the resulting zip files are not quite right. On Unix systems, the command unzip -xa will convert line endings to the system convention (LF only), even if they come from Windows (LF-CR endings). However, this requires that the zip identifies text files, and 7-Zip marks everything as binary!

I did a bit of hunting around, and found Info-ZIP, where after a bit of hunting about you can find zip and unzip binaries for Windows. These give me Unix-like capabilities on Windows, so I can make the appropriate files, alter line endings on zipping/unzipping and check the results.

That led me to take another look at the batch file I use each time I release something to CTAN: doing it by hand is an unreliable business! I’ve reworked it quite a bit, to generalise everything and also add a few tweaks. For anyone interested, the file is available here. It’s called make, so that you get Unix-like abilities on Windows. The file has to be customised for each package I write, but most of this version is generalised, and can be altered using a few settings.

set AUXFILES=aux cmds dvi glo gls hd idx ilg ind ist log los out tmp toc
set CLEAN=bib bst cls eps gz ins cfg pdf sty tex txt zip
set DOCEXTRA=\AtBeginDocument{\OnlyDescription}
set INDEXFILE=gglo
set PACKAGE=achemso
set TEX=achemso-demo

Anyone at all familiar with batch files will see that this is a block of environmental variables: in this case, these are the settings for my achemso package. Most are pretty obvious settings, but in case anyone wants to use the file for their own purposes:

  • AUXFILES File types to delete after every run: throw away files.
  • CLEAN File types deleted only if make clean is run: useful stuff.
  • DOCEXTRA Inserted when creating documentation, can be anything. I don’t typeset the code for my packages in the release documents, hence the \OnlyDescription setting.
  • INDEXFILE This is always gglo for documents using the ltxdoc class, but is l3doc if using the LaTeX3 class l3doc.
  • PACKAGE Pretty obvious, the bundle name!
  • PDF The names of PDF files to add to the documentation part of a TDS zip. By having this as a setting, special effects (demo documents, for example) are possible.
  • TDSROOT. Almost always as given for a LaTeX package.
  • TEX A list of .tex files to copy into the TDS archive: to avoid any testing files, not all .tex files are copied.
  • TXT The names of text files to copy to the documentation directory
  • UNPACK The file(s) to run to unpack the package. I use .dtx files that are self-extracting, but the traditional method is to have a separate .ins file.

If the batch file proves useful to enough people, I might write some proper documentation and do a bit more generalisation.

With all of that in place, I can hopefully keep Unix-based LaTeX users happy without too much work!