End of TeX Live in Debian?
It sounds crazy, but I am seriously considering to ask for the removal of the TeX Live packages from Debian. Although this sounds crazy, especially considering the consequences:
- several packages will FTBFS
- no TeX system available anymore
- Debian looses one of the oldest open source program at all
the current development is probably forcing me to do this step. I am slowly loosing the optimism that there is a reasonable way for TeX Live to survive in the more and more radicalizing Debian community. And even if I do not ask for removal, the time of TeX Live as it is now in Debian is counted. The reason are serious bugs that are reported concerning non-source file distribution.
The idea was originally that a program is accompanied by the source code. But it has been extended to any document, based on the idea that the preferred format of modification must be shipped, and the rest must be generated during the build process.
The first bug that rolled in concerned the shipping of flash files. Some of the included flash files are missing the sources, this can be fixed. But the new requirement is that flash files have to be also rebuild from source. This shot off a new serious bug in the TeX Live packages, that I will fix by simply removing the flash files, leaving Debian users with crippled installations.
There are only a few of these flash files, and we can live without them. But message 31 of the first mentioned bug report states the same future for pdf files, too. Now, TeX Live probably ships around 6000 pdf files, some of them requiring an non-trivial build sequence. I will definitely not start writing build scripts building each and every of these documentation files.
[Update 2014-04-14 I released that this is not only about pdf files. A lot (my guess is about 70% or more) of all the sty/cls/tex/mf/tfm files are in principle generated from something else, namely the dtx (or from mf) files. In TeX Live upstream we are having a hard time building all the files (see ctan2tds script) and often manual intervention is needed. So yes, all the cls/tex/sty/mf/tfm files are also on the brink of extinction!.]
Funny side remark: The TeX Live Project itself has no problem with using precompiled pdfs, as long as the sources are available – now please Debian (zealots), take an example.
The options where to go from here are interesting:
- as suggested in the bug report, ask for exception
- remove all of TeX, leave a crippled Debian and hundreds of packages with FTBFS
- do not ship any documentation
- find someone that does the work
Concerning the first option – I don’t understand why we need to install rules only to create exceptions. It just keeps me in a position of permanent begging – please continue this exception etc. This is not how I consider this case should be solved.
Concerning the second option – I don’t mind, I can use TeX Live upstream, and it is anyway more complete and uptodate than the Debian version. We would only ship a meta-package that tells the user: “You have to install TeX Live or another TeX distribution separately from Debian!”. That sounds like an easy options, besides that it will force the removal of many other packages due to FTBFS. Great cleanup in Debian 😉
The third version is easy, but also not without risk, since some authors of TeX packages require their run time files to be distributed together with the documentation. Good luck. Ah, and yes, I forgot the users – the users who are our prime concern in Debian – at least that is what I learned years ago. Seems that we have forgotten this virtue.
The last option is that someone takes over TeX Live packaging from me – well formally not me but the Debian TeX Team. Just some random data: I am currently the only one building, testing, fixing the packages. I spend lots of time developing the Perl scripts allowing for automated packaging. If someone wants to come up with new packaging, he should count a man-year to get it into a decent state. Good luck.
All sad words, but honestly, my optimism that the situation will improve is minimal. Thanks to Debian radicals.
Actually, it’s only required that we ship:
The preferred form for modification (“source”) for everything shipped
Whatever tools are needed to build it
Actually building the derived files is merely a “best practice”, and even then only if consequences aren’t too bad; losing our entire TeX distribution is obviously too bad.
(I admit that this could still probably result in the loss of some quite useful PDFs, at least if the project were to determine that someone still has the source to them but isn’t sharing, but I really don’t think we need to go on any witch hunts here.)
Fonts are a bit tricky, of course, because it’s hard to tell how exactly they were built. However, if we happen to notice that there are sources that are [supposed to be] usable to build them in an automatic fashion, it would be a violation of the social contract not to at least *investigate* the feasibility of this.
It is kind of strange that suddenly discovering a more preferred form for modification that needs a non-free tool to convert to what we want to ship in Debian would demote something from “main” to “contrib”, though.
Oh darn,
ol</code andliaren't on the whitelist; that second paragraph was supposed to be an ordered list.… and I can’t spell my own email address …
Hi Samuel,
thanks for your comment. I agree with your statement, that we need to ship the sources. But it seems more and more accepted practice to regard not actually building also as serious, that is RC bug. In TeX Live there are a few flash files (see later comment), but about tens of thousands of pdfs.
The point of my rant was that, in my opinion this is a slippery slope we are fighting on. We require this for binaries (programs), but soon it has to be for every constructed document. And as the discussion on fonts is showing, it is going overboard. Fonts are in most cases the preferred format of modification, and still there are bugs about rebuilding the fonts.
Anyway, let us see how it develops. For sure I will not ask for exceptions, I am against exceptions. If the rules are too strict then they are too strict. But then we have to carry the consequences.
For the flash part I am downloading the source I making patch.
Will you consider to sponsor me (I will package the adobe part)
Bastien
Hi Bastien,
thanks for your proposal concerning the patch. It would be great if you could provide a patch, even better if it would be against the meta-packaging as found in the texlive-nonbin git repository. The rules file is in all/debian/rules.in and is eperl preprocessed. The other Debian data like quilt patches are in texlive-extra/debian/ (as expected).
You don’t need a sponsor, just send me git merge requests or patches and I will include them in the next release.
Thanks
Norbert
BTW could you add to texlive debian/ a TODO.debian ? You said you are alone but could you please add some item to solve. I can help on my free time.
Bastien
Thanks Bastien,
Currently the building of new packages is semi-automatic (see do-all script).
What is currently on the top of the list is integration of the new binary sources. But here we are stuck already, since we need libpng and it seems freetype etc is still linked against the old libpng, which results in a mix of libpng usages and broken binaries failing the tests.
Here a lot of work and testing has to be done – how to work around the current situations of libpng in Debian (it is so bad that we have still libpng 1.4 as the stable against which all packages are built, arggg)
Hi! I have two comments I think:
1) Does that include Ubuntu? (Not that I’m concerned personally, but people on TeX.SX will soon be.)
2) Samuel Bronson: Your post looks like “rules in order to have exceptions”. The issue here is not technical, therefore it IMHO has no technical solution. The issue is that some people have ideals but no eyes, ears and brains.
Hi tohecz,
thanks for your comment.
ad 1) well, not directly, since I am not responsible for the actual Ubuntu packages. But since Ubuntu just pulls what I am doing in Debian, it might have an influence how it develops in Ubuntu, too.
I just updated the post to mention that practically all files shipped are generated: tex/cls/sty/mf from dtx in most cases, and tfm files from mf, and so on and so on.
So in fact we have to remove everything, if we are serious – and looking at this thread http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-March/007253.html I think several people are really serious about it – then we remain with either nothing, or someone else takes over.
Hi Norbert,
Interesting post: I guess borne of frustration. One issue that occurs to me here is that at least as far as the TeX community (CTAN, etc.) is converted, there has never been a need to distribute build tools, just the sources and so forth. For example, when Vedran and I inherited
beamerfrom Till Tantau, it came with abashscript to actually create the documentation. That script is not very sophisticated, but as it works well enough for me to send updates to CTAN I’ve never bothered to work on it further. Similarly, for my ‘own’ material I have a couple of scripts (a Windows batch file and a Unix-styleMakefile) that do the work. Those probably do function for most platforms (untested!), but I’ve never distributed them to CTAN as I don’t really think end users should need to build the docs themselves: I do it for them (and encourage them to use TeX Live or MiKTeX to install).Thanks Joseph for your comment. I agree completely. In TeX Live we have stopped building provided pdfs a long time ago. We actually ask authors to upload built documentation. In some cases one would need very strange setups (language, LC, specific patterns, etc), in some cases hand massaging.
Unfortunately, this is currently the way where Debian is heading for. Looking at the JavaScript discussions I see interesting things coming in my direction.
Let us see what is happening. For now I am adjusting the severity of all those RC bugs coming in with respect to this. But that might become unacceptable at some point.
Another one to consider is the formats, in particular LaTeX2e. There’s no Unix script to build LaTeX2e from sources: the team used to use
cons, but that is now a real pain for us, and Frank has recently written some (Windows) batch scripts to do the same job (realism: the people who need to build this all have Windows boxes).Actually, I guess this is not so important: most of the issues with the LaTeX2e build scripts are actually about making sure that the test parts work without any influence of other installed files.
FWIW, there should still be an option to install TeX Live via package managers. A frequently used approach is to install an installer script with a package, and have that script do the rest of the installation. Since the recommended installation mode for TeX Live is already such a script, this strikes me as entirely possible.
(And actually preferable since it’s easier to maintain and keep up-to-date for users.)
Hi Raphael
thanks for your comment. Unfortunately this is no option, as TeX is necessary to build several packages on the build-daemons, where no user interaction is possible. Thus, we have to ship a ready and workable TeX installation out of the box.
Of course everyone is free to install a local copy of the original TeX Live, and there are many guides out there.