TeXLive modular ebuilds ready(?) for the main portage tree

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

About these ads

20 Responses to “TeXLive modular ebuilds ready(?) for the main portage tree”

  1. Francois Says:

    I have been using the ebuild from bugzilla but I haven’t switched to the modular one yet on my x86 machine. I am ready to test it on ppc has soon as it hit the main tree or a suitable layman overlay [my ppc machine is at work and I can only do svn over https not http there].

  2. gentoofan23 Says:

    Hi! I am from the amd64 arch team but I definitely wouldn’t say I am a spokesperson from that team.

    I personally would prefer an extra level of testing(esp. to make sure all the deps are ok.) so that when(if?) stabilization comes around, everything will be much simpler.

  3. Uzytkownik Says:

    Thanks for information. Since TeX Live is the recommended distrybution I download it now (PS. As I understend there will be packages separated in the near feature and it will be possible to downloads only parts I need).

  4. Giacomo Says:

    Hi. From what I see on the site texlive is HUGE. How much disk space would virtual/latex-base need?

  5. aballier Says:

    virtual/latex-base, assuming it’ll use texlive, will be about 150Mo I’d say

  6. CandyShopGirl Says:

    Hail!

    What do you think about love? >:)

  7. CandyShopGirl Says:

    Wazzup!

    What do you think about love? >:)

  8. Whut Says:

    Just want to thanks for texlive ebuilds.

  9. orionbelt Says:

    Bonjour Alexis,

    Just a quick note to thank you for taking over the texlive package. I had already started having problems with the abandoned tetex, and I was becoming anxious (and jealous…) seeing colleagues using Debian be able to run texlive for many months now…

  10. Idetrorce Says:

    very interesting, but I don’t agree with you
    Idetrorce

  11. Michael Tim Says:

    I love your site!

    _____________________
    Experiencing a slow PC recently? Fix it now!

  12. Heartburn Home Remedy Says:

    This topic is quite hot in the net right now. What do you pay the most attention to while choosing what to write about?

  13. Random T. Says:

    Hey, cool tips. I’ll buy a glass of beer to the person from that forum who told me to visit your blog :)

  14. enzymnnex Says:

    Sweet blog. I never know what I am going to come across next. I think you should do more posting as you have some pretty intelligent stuff to say.

    I’ll be watching you . :)

  15. Mark Roberts Says:

    Nice blog, keep up the good work and thank you for sharing. :)

  16. Raul Says:

    Thank you for writing this blog. I Have been searching a long time to discover this information.

  17. sony ericsson j110 i Says:

    Really nice post. Very Informative and helpful post.

  18. Mulch Says:

    Hey, I think your very on target with this, I can’t say I agree with you completely , but its not really that big of a deal .

  19. sonicrafter review Says:

    Good work buddy, keep it up.

  20. Johna977 Says:

    Valuable information. Fortunate me I discovered your web site by chance, and I am surprised why this coincidence didn’t happened in advance! I bookmarked it. eabbdeadgkab

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: