1 |
Dear list, |
2 |
|
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. |
7 |
|
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. |
11 |
|
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. |
18 |
|
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. |
23 |
|
24 |
|
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. |
41 |
|
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. |
45 |
|
46 |
|
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. |
51 |
|
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) |
60 |
|
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... |
63 |
|
64 |
|
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. |
68 |
|
69 |
|
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. |
75 |
|
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 ;) ). |
81 |
|
82 |
|
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. |
87 |
|
88 |
Alexis. |
89 |
|
90 |
|
91 |
[1] http://overlays.gentoo.org/dev/aballier/ |
92 |
[2] http://dev.gentoo.org/~pclouds/texlive/overlay/ |
93 |
[3] http://www.tug.org/svn/texlive/trunk/Master/LICENSE.TL?view=markup |
94 |
[4] http://www.tug.org/svn/texlive/trunk/Master/LICENSE.CTAN?view=markup |
95 |
[5] http://www.tug.org/texlive/copying.html |