CC-ing the bugs list does not work?
by Vasile Gaburici
I've CC'd <fedora-fonts-bugs-list(a)redhat.com> on some bug reports I've
sent to <tex-live(a)tug.org> (they don't use a bug tracker anymore), but
the archives of fedora-fonts-bugs-list do show these messages... Does
anyone know why?
15 years, 7 months
- 2
- 1
Re: Very nice of you to write the tl2rpm converter
by Vasile Gaburici
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(a)gmail.com> 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(a)gmail.com>
> Date: Sun, Aug 10, 2008 at 8:19 AM
> Subject: Re: TeXLive 2008 in F10?
> To: Jonathan Underwood <jonathan.underwood(a)gmail.com>, Patrice Dumas
> <pertusus(a)free.fr>, Development discussions related to Fedora
> <fedora-devel-list(a)redhat.com>
>
>
> 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...
>
15 years, 7 months
- 1
- 0