Gentoo Archives: gentoo-dev

From: Alexis Ballier <aballier@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] TeXLive modular ebuilds ready(?) for the main portage tree
Date: Sun, 30 Sep 2007 19:04:49
1 Dear list,
3 As some of you may or may not know, I've been working on modular
4 texlive ebuilds[1], based on work found on b.g.o and pclouds work [2].
5 I wanted to send a mail earlier but time was lacking to fix the few
6 remaining bugs.
8 I've had several success reports, and fixed the remaining (known) bugs
9 there. I was thinking that it might be time to integrate this to the
10 official tree, as a first shoot under package.mask.
12 The layout I've been using is a modular one:
13 - texlive-core package that builds the required binaries. That's the
14 only one that should be system dependant.
15 - several texmf modules based on upstream "collection"s (that's how
16 they call them) that agregates packages from CTAN in some more or less
17 independant categories.
19 I've tried to remove as much as possible programs from the -core
20 package, as long as they had their independant ebuilds equivalent and
21 added the independant packages as dependencies of the texlive meta
22 ebuild.
25 As you might guess it, having a modular layout can give dependencies
26 problems. I was thinking about adding some (new style) virtuals to
27 handle them :
28 - virtual/tex-base : programs that need only standard tex binaries or
29 libraires (like kpathsea) but do not need it to compile latex files for
30 example. There are a very very few of such packages and are ok with the
31 next virtual, so I dunno if that one is really necessary, apart for
32 reducing deps to the minimal set.
33 - virtual/latex-base : packages that need a (basic) latex, for example
34 to compile their documentation. This virtual will help preventing from
35 having circular dependencies between ebuilds (esp. the meta ebuild and
36 its dependencies)
37 - virtual/latex-full : a full latex distribution installation, what
38 other tex distributions like tetex provide. This one can use the current
39 old style virtual (virtual/tetex) instead of being a new one, but the
40 name is better imho.
42 So in the end, only latex-base is strictly required to merge this.
43 tex-base and latex-full have their improvements but can benefit from
44 discussion here.
47 Everything in [1] could still benefit of any kind of reviewing,
48 especially the eclasses. I'll also need to write a more decent guide on
49 how to use/switch to those ebuilds, so that it can be put on the
50 website.
52 The only (known) bug still left so far is that metapost (mpost) isn't
53 useable on hardened kernel, it gets killed. It is not a regression from
54 tetex, but apparently nobody ever noticed that. Now that ebuilds
55 generate the format files themselves in src_compile (this way we can
56 improve QA imho), instead of having texmf-update doing it in
57 pkg_postinst, some ebuilds will fail to install instead of silently not
58 creating the format file. (though texmf-update will still recreate the
59 formats so that they get updated with the texmf tree)
61 Something that annoys me is the license : there is [3], [4] and [5], so
62 GPL-2 might probably be fine, but I'm definitely not a lawyer...
65 In the (very hypothetic) case where nobody would have anything to add
66 there, I'll start merging this to the main tree, but definitely not
67 until the next week as I'll be away from wednesday to sunday.
70 And of course, many thanks to all the people who helped there: the
71 early testers when documentation was lacking but not bugs, the people
72 who suggested improvements (be it to ebuilds, the packaging layout or
73 documentation), bug fixes, reported bugs, or just mailed me about a
74 successful installation.
76 Now a question to arch teams : Should I keyword this for systems I've
77 tested it or just add without keywords and let you do another layer of
78 checks ? I've been using it on ~x86 (and hardenend but mpost had
79 problems), ~amd64 and ~ppc64 (this one has some missing deps, but don't
80 worry I'll poke you as soon as I'll have done extra checks ;) ).
83 As a side note, I'll have to send 1.3k+ files to distfiles-local as
84 upstream does not provide versionned names of the source files, for a
85 total of ~700-800M. Since this is huge, I hope infra has no particular
86 objection to it.
88 Alexis.
91 [1]
92 [2]
93 [3]
94 [4]
95 [5]


File name MIME type
signature.asc application/pgp-signature