Some authors have started experimenting with packaging their materials
in a .zip
file that is ready to unzip into a user's TeX tree.
That is, instead of uploading to CTAN in the traditional format
xxx.zip:
+--xxx/
+--README
+--xxx.ins
+--xxx.dtx
+--xxx.pdf
an author may send this.
xxx.zip:
+--tex/
+--latex/
+--xxx/
+--xxx.ins
+--xxx.dtx
+--xxx.sty
+--doc/
+--latex/
+--xxx/
+--README
+--xxx.pdf
This layout follows the TeX Directory Standard. We say that these materials are TDS-packaged.
The goal of TDS packaging is to make installation easier.
The hope is that
end users can just move to the directory on top of their local tree,
perhaps
/usr/local/share/texmf-local or
C:\localtexmf,
unzip the file, and finish by running texhash.
This simplicity is a great advantage for packages with elaborate installs
such as fonts.
However, TDS-packaged material has a number of disadvantages, also.
The most serious is that TDS-packaging is not a substitute for a distribution's package manager: users must watch for new versions of a package and by-hand update their materials, including deleting any files in the old version that do not exist in the new version.
Another disadvantage is that TDS-packaging is only useful in the time between the package being uploaded or updated and when it gets into the distributions. (Some packages are not in the distributions but most are.) So the additional work, and potential for confusion, may only result in a gain for a short time.
To us this appears to be an experiment. It may be that the advantages prove to outweigh the disadvantages but we do not yet know.
However, this experiment does raise issues. For one thing, TDS-packaged materials are significantly more tedious to browse than the traditional format, and making packages harder for our visitors to understand is bad both for our visitors and for the package authors, whose work does not get the attention it deserves.
Another disadvantage is that the xxx.zip file
that we now place at
macros/latex/contrib/xxx.zip
would not work as intended by TDS authors.
That file unzips to a
top-level directory of xxx/
so that packages would actually end on the user's disk in this way.
/usr/local/share/texmf-local/
+--xxx/
+--tex/
+--latex/
+--xxx/
+--xxx.ins
+--xxx.dtx
+--xxx.sty
+--doc/
+--latex/
+--xxx/
+--README
+--xxx.pdf
Note that the tex/ subtree there is not
immediately below texmf-local/.
This is not TDS compliant, and the TeX system of potential users
will not be able to find this package.
In addition to those disadvantages, converting all packages to the TDS format would be a large undertaking and our archive would be awkward if it is partly one way and partly the other.
On the other hand, we welcome innovation in the community.
Authors who do not wish to experiment should continue what they are doing. We ask that authors wishing to try TDS packaging do this.
.zip or a
.tar.gz bundle of your material.
Lay the material out in the traditional way.
<pkg id>.tds.zip
that contains the TDS packaging of your materials. We will
not install this in the regular browsing tree but instead will
put it below the install/ subtree.
For instance, an author may send us xxx.zip with this layout.
xxx.zip:
xxx.tds.zip
+--xxx/
+--README
+--xxx.ins
+--xxx.dtx
+--xxx.pdf
We
install into
macros/latex/contrib/xxx the files
README, xxx.ins,
xxx.dtx, and xxx.pdf.
We generate a macros/latex/contrib/xxx.zip
so archive visitors can download all these files at once.
The xxx.tds.zip file which unzips into the TDS layout
shown earlier we put
in install/macros/latex/contrib/xxx.tds.zip.