During the past months TeX Live has been in ~arch and seems to be working quite well for everybody since I do not receive that much bug reports, and the ones I’ve had are now fixed. However I’ve seen lots of people asking me: “Hey, where do I find the latex package foo ? I need it to compile my latex document.”.
The reason for this is that TeX Live 2007 ebuilds are split into several smaller ebuilds rather than having one single ebuild, like that was the case for teTeX which in the end was very hard to update and forced everybody to have hundreds of TeX packages that they would never use.

For that “problem”, Alexandre ( ‘Untux’ on the forums) has written a very nice script: texmfind. He has collected the list of files from most of TeX packages we have in portage, based on a TeX Live installation, and written a grep wrapper that digs into the data file to give you what package you should install in order to have what file.

For example:

$ texmfind moderncv.cls
dev-texlive/texlive-latexextra [1 file]
moderncv.cls

Found 1 texmf file in 1 ebuild.

Of course, it is now in portage as dev-tex/texmfind and it comes with a nice man page for a more advanced usage than this toy example.

Now it seems most people have no reason not to switch to TeX Live, and I really recommend everybody to migrate. Moreover, TeX Live should be ready to go stable now and I would really appreciate some feedback from stable users running TeX Live as a TeX distribution instead of teTeX. This can also include filling a stable request on bugs.gentoo.org as this will probably ensure that I have not messed up anything with the dependencies and that I’m not mistaken when saying it should be ready to go stable.

For those who do not read -dev ml and might be interested in testing / helping:

As some of you may or may not know, I’ve been working on modular texlive ebuilds[1], based on work found on b.g.o and pclouds work [2]. I wanted to send a mail earlier but time was lacking to fix the few remaining bugs.

I’ve had several success reports, and fixed the remaining (known) bugs there. I was thinking that it might be time to integrate this to the official tree, as a first shoot under package.mask.

The layout I’ve been using is a modular one:
- texlive-core package that builds the required binaries. That’s the only one that should be system dependant.
- several texmf modules based on upstream “collection”s (that’s how they call them) that agregates packages from CTAN in some more or less independant categories.

I’ve tried to remove as much as possible programs from the -core package, as long as they had their independant ebuilds equivalent and added the independant packages as dependencies of the texlive meta ebuild.

As you might guess it, having a modular layout can give dependencies problems. I was thinking about adding some (new style) virtuals to handle them :
- virtual/tex-base : programs that need only standard tex binaries or libraires (like kpathsea) but do not need it to compile latex files for example. There are a very very few of such packages and are ok with the next virtual, so I dunno if that one is really necessary, apart for reducing deps to the minimal set.
- virtual/latex-base : packages that need a (basic) latex, for example to compile their documentation. This virtual will help preventing from having circular dependencies between ebuilds (esp. the meta ebuild and its dependencies)
- virtual/latex-full : a full latex distribution installation, what other tex distributions like tetex provide. This one can use the current old style virtual (virtual/tetex) instead of being a new one, but the name is better imho.
So in the end, only latex-base is strictly required to merge this. tex-base and latex-full have their improvements but can benefit from discussion here.

Everything in [1] could still benefit of any kind of reviewing, especially the eclasses. I’ll also need to write a more decent guide on how to use/switch to those ebuilds, so that it can be put on the website.

The only (known) bug still left so far is that metapost (mpost) isn’t useable on hardened kernel, it gets killed. It is not a regression from tetex, but apparently nobody ever noticed that. Now that ebuilds generate the format files themselves in src_compile (this way we can improve QA imho), instead of having texmf-update doing it in pkg_postinst, some ebuilds will fail to install instead of silently not creating the format file. (though texmf-update will still recreate the formats so that they get updated with the texmf tree)
Something that annoys me is the license : there is [3], [4] and [5], so GPL-2 might probably be fine, but I’m definitely not a lawyer…

In the (very hypothetic) case where nobody would have anything to add there, I’ll start merging this to the main tree, but definitely not until the next week as I’ll be away from wednesday to sunday.

And of course, many thanks to all the people who helped there: the early testers when documentation was lacking but not bugs, the people who suggested improvements (be it to ebuilds, the packaging layout or documentation), bug fixes, reported bugs, or just mailed me about a successful installation.

Now a question to arch teams : Should I keyword this for systems I’ve tested it or just add without keywords and let you do another layer of checks ? I’ve been using it on ~x86 (and hardenend but mpost had problems), ~amd64 and ~ppc64 (this one has some missing deps, but don’t worry I’ll poke you as soon as I’ll have done extra checks ).

As a side note, I’ll have to send 1.3k+ files to distfiles-local as upstream does not provide versionned names of the source files, for a total of ~700-800M. Since this is huge, I hope infra has no particular objection to it.

[1] http://overlays.gentoo.org/dev/aballier/
[2] http://dev.gentoo.org/~pclouds/texlive/overlay/
[3] http://www.tug.org/svn/texlive/trunk/Master/LICENSE.TL?view=markup
[4] http://www.tug.org/svn/texlive/trunk/Master/LICENSE.CTAN?view=markup
[5] http://www.tug.org/texlive/copying.html

There are now two x264-svn ebuilds in ~arch :

media-libs/x264-svn : this one installs the library, headers and pkgconfig files needed by the other packages (for ex. ffmpeg)

media-video/x264-svn-encoder : x264 encoder that was previously installed with x264-svn and a gtk use flag with which you can install a gtk frontend to this encoder.

Why that ? Eh, let’s have a look at it :
- x264 encoder can use gpac for mp4 output
- gpac can use ffmpeg
- ffmpeg can use x264 libs

If you want all of these features, then you hit a circular dependency problem.

Moreover, previously if you wanted to install x264 gtk frontend then libx264.so would have been linked to x11… why ? I don’t know, it’s not needed. Now this is no longer a problem since they are different packages.

My first blog post using drivel

Hi,

this is my first blog post, trying to use categories

This is a test

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!