Actually, the main problem I see with that single spec is update handling. When a single source of those many thousands changes, you'd have to rebuild all the binary rpms, and they'll all get a new release number. Unless there's some hack to avoid this, the Fedora user would have to update all the texlive rpms every time, thus negating any benefit of having TL split in those packages. Also, I think you need a way patch that spec after it's generated or perhaps as it is generated. Some reasons to do this: * packaging the TeX OpenType fonts only for TeX is a no-no these days * some TL packages have incorrect/missing license. For instance glyphlist, which contains Adobe's glyphlist.txt, (which is taken from lcdf-typetools in TL2008) and IMHO needs "Redistributable, no modification permitted". BTW, in TL2008 that file is required by lcdf-typetools and dvipdfmx, but in Fedora's TL 2007, dvipdfmx includes Adobe's file in its own rpm, so the rpm probably has an incomplete license field because of it; should add "... and Redistributable, no ..." like poppler has. * some packages should probably not be built from TeXLive, so you probably need blacklist. Examples: - The Gyre fonts (currenly) have a licensing issue. - Some packages like lcdf-typetools (in which all programs except one don't actually need TeX at all) are probably better built outside of TeXLive (with subpackages in this case). - You probably want to disable tlmgr. Unless you can patch it to install rpms instead, of course, but that seem difficult to hack... * the TL2008 texmf.cnf file uses $SELFAUTOPARENT. This can cause trouble with binaries sitting outside its tree. If the user installs any binaries of its own (say in /usr/local/bin), they won't work with the default cnf. See: http://tug.org/pipermail/tex-live/2008-August/017338.html As matter of approach, packaging TL binaries surely is convenient, but there are some potential problems: * odd shared libraries used. For instance TL2008's lcdf-typetools did not work on Fedora 9 out of the box because of missing libstdc++.so.5 (granted it's in a compat package, so when the RPM is built the right dependency would probably get added), but that dependency is gratuitous in this case. * TL builds a lot of stuff statically liked. A prime example is XeTeX. This one is tricky because it uses modified versions of some libraries (ICU), some libraries which don't have any modifications but are also included in XeTeX tree. Hope this helps, Vasile On Mon, Sep 1, 2008 at 2:16 AM, Vasile Gaburici <vgaburici@xxxxxxxxx> wrote: > It would have been even nicer had you cc'd fedora-devel-list... > > For those that don't read the tex-live@tug list, or the ambassadors' > list, here's the tl2rpm (prototype) announcement: > http://tug.org/pipermail/tex-live/2008-August/017190.html > > My main concern is that %post actions will turn out quite hairy, see > below (you were probably on vacation then): > > ---------- Forwarded message ---------- > From: Vasile Gaburici <vgaburici@xxxxxxxxx> > Date: Sun, Aug 10, 2008 at 8:19 AM > Subject: Re: TeXLive 2008 in F10? > To: Jonathan Underwood <jonathan.underwood@xxxxxxxxx>, Patrice Dumas > <pertusus@xxxxxxx>, Development discussions related to Fedora > <fedora-devel-list@xxxxxxxxxx> > > > Initially I thought we could do without their installer, because I > found only 4 types of "execute", i.e. post install script actions in > the master texlive.tlpdb on CTAN. Then I had a look at their new > packager's sources: > http://www.tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/. Besides > the 4 generic "execute" types, there are plenty of hardcoded > package-specific things in TLPostActions.pm. > > So, I don't see an easy way of dealing with this. Duplicating all that > stuff in rpm post scriptlets would be highly unmaintanable. The only > sane way would be to install their packager library first, and to > execute post actions from there as needed, which needs at least a > wrapper script since that code is Perl. It's more than I have time for > this weekend... > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
