Request for comment - How to improve TeX in Slackware?
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I'd like to find a way to update the components that make up teTeX to make things a little more modern. TeXlive really isn't an option due to the size. If we had that, it'd be at least 50% of the total install disk space. :/
I would like to invite the TeX users in the Slackware community to give feedback on this issue.
I envisage a discussion of issues like:
What would be an easy addition to TeX that would aid usability?
My own example here would be that I needed to add the subscript.sty so that I could do subscripts. As this is a 559 byte file it is a very small addition that would aid usability.
What are the advantages that you get from TeXlive?
I accept that not using a modern version of TeX means that support from TeX forums is nigh on impossible.
Are TeX users happy with being able to install TeXlive from SlackBuilds.org on default Slackware or should it form part of the standard distribution?
I had a chat with a texlive upstream maintainer at FOSDEM about this and there are some options we could persue. Alas I did not have time yet to look into it and probably won't for the forseeable future. But maybe someone else finds time, so here's what I got from him:
The texlive installer itself already has support for dividing the package set into smaller subsets, using either collections or schemas. So we can simply run the texlive installer, tell it what subsets we want (there is already a tetex schema), install in a temp location and create a new texmf tarball from that. Users would be able to get the non-included stuff using tlmgr.
tlmgr would need to install in a non-packaged location, which I'm not sure if or how it would be possible. There is a patch somewhere for tlmgr to make it install addon tex packages in the users homefolder, which would be ideal, but since it's not upstream yet would need testing.
I was considering downloading and running the net-installer they provide and pointing it at something like /opt/texlive (owned by something along the lines of a 'texadmin' user). I'm not very knowledgeable with tex though so I don't know how well this might work.
Maybe this is a case where packaging it under the distros native package management doesn't add any value, and just makes things more complicated.
I think packaging parts of texlive (some minimal schema or something) will just complicate things - users who need additional tex stuff will install them with tlmgr, and than part of their tex installation will be managed by the pkgtools, and the other part by the texlive system. It could get very confusing and hard to maintain.
It seems to me the best option is to let the tex packaging system mange the whole thing. Using an external packaging mechanism for such an integral part of the system might seem to go against the keeping it simple philosophy, but I think it is better than the alternatives.
So, how can it be done? perhaps it is possible to include a sort of partial repository of texlive, with only the necessary stuff, on the installation media, so we can run the tex installer to get the basics from there during slackware installation. This way we actually have a small tex collection on the media but we manage it with texlive's tools, and the user can then use tlmgr if he needs additional tex stuff.
Now that I put this idea on paper (screen actually) it looks a bit complex, also I haven't checked if this is possible at all and there are surly some pitfalls to consider, but I still think its a good idea.
Being a mathematician by trade, I use LaTeX extensively. I prefer texlive because it includes mathdesign, which gives me access to the greatest font family of all time. Also, my dissertation required idxlayout to conform with school formatting guidelines. Neither package is present in Slackware tetex. I could probably survive without Charter, but idxlayout really saved my hide (I don't want to start hacking low-level TeX).
tetex is in an optional package group, isn't it? I would just junk it. I know it's a dependency in SBo texlive script, but they can work around it, can't they? It would be pretty silly if TeX was a hard requirement for building TeX.
Erm, I asked about finding a way to update teTeX, not for opinions about texlive. We've actually spent quite a lot of time looking at texlive, and my opinion is that it would be far more difficult to make texlive suitable for Slackware than it would be to update teTeX. The ability to build a subset of texlive is not enough if the enormous source tree would still need to be shipped. Adding a few more packages to teTeX (if it got an update) would not be out of the question. The problem with texlive is that they've added *everything*, far more than the average user of TeX has any use for.
Which brings up a side comment... when I started this project, it really wasn't my intent to provide every possible package, application, desktop, etc. My goal was to make a platform upon which things could be built easily and that followed upstream as closely as was possible. Of course, some applications had to be included, but the idea was to try to stick to the essentials that everyone would miss if they weren't there.
Guess maybe we got a bit off track, eh?
I'm not unhappy with how things have turned out, and I'm not looking for removal ideas. However, it remains a command prerogative to try to keep bloat from continuing unchecked as much as possible.
As far as including just a build script for texlive in /extra, if it's already maintained at slackbuilds.org I don't see a big advantage.
I (in)directly use teTeX mostly via LyX these days, although I have created or edited a few latex documents more directly at times. I have not hit any limits with the Slackware teTeX package for my own limited use.
As for additions, I have collected/created a small subset of document classes over time that I now add to each new install.
So the only thing that comes to mind to make the default teTeX package more useful would be to add an extended collection of document classes, although those tend to come from various sources so I am not aware of any single source that would fit well within the Slackware "way".
FWIW - thank you for resisting the inclusion of texlive. I think that anything that would consume 50% of the installed size while providing no clear benefits to the mythical average user qualifies as the poster child for bloat!
I looked into texlive a year or two ago (prompted by another thread here as I recall) just to try to understand what benefits came with the large size, and I did not find any clear answer. Perhaps if I were in the publishing business, but then I would probably install it myself anyway.
Erm, I asked about finding a way to update teTeX, not for opinions about texlive. We've actually spent quite a lot of time looking at texlive, and my opinion is that it would be far more difficult to make texlive suitable for Slackware than it would be to update teTeX. The ability to build a subset of texlive is not enough if the enormous source tree would still need to be shipped.
Well, that's basically what I meant with
The texlive installer itself already has support for dividing the package set into smaller subsets, using either collections or schemas. So we can simply run the texlive installer, tell it what subsets we want (there is already a tetex schema), install in a temp location and create a new texmf tarball from that.
We could create a smaller source tarball ourselves and ship that instead of the huge one from upstream. And IF the tlmgr setup works good enough I don't see how this is harder than handpicking updates into tetex. I do see how it has a higher barrier to try it though
I use LaTeX a lot and it didn't take long using it in slackware before I needed something that was not included in teTeX. Robby Workman's TeX Live slackbuild is great but it must be said that TeX Live is ridiculously huge.
As far as just packaging goes, if Pat wanted to just replace/update teTeX to modernise it (at least with/to something that is still supported) that might be achieved by following ppr:kut's suggestion of using a similar-sized schema from TeX Live itself. The problem is *the source*. If the source is to also be included with slackware it'll be just too damn big. If TeX Live's source was in smaller bits that might fix that problem but as far as I know it's all-or-nothing.
Maybe a good compromise is to stick with teTeX (for the moment) but in the spirit of dugan's suggestion, ``upgrade'' Robby's TeX Live slackbuild to /extra (with references to the source in the README), possibly also with some environment variables to allow a bit more control over what ``schema'' to build?
Erm, I asked about finding a way to update teTeX, not for opinions about texlive.
Please, you have to accept that tetex is not an option any more.
I (Thomas Esser) have decided not to make new releases of teTeX any more (May 2006). The information below might get out of date as time goes by. I suggest anybody interested in teTeX to join the TeX Live project.
Updating tetex would be an attempt to create your own TeX-distribution. You wouldn't want to do that, for the same reason Thomas Esser stopped doing it...
I have skipped the TeX install from slack for the last five years, and installed TeXLive instead using their install. Slackbuild adds just another layer, which I was not ready to do. Pity, but necessary for serious TeX users.
I use everyday LaTeX and also installed TeXLive using their install. It needs not to be installed in the /usr or /usr/local trees, so it is in fact somehow independent of Slackware. One needs of course to edit the PATH and put in it the path to TeXLive binaries. That's all. TeXLive has also its own package management tool.