Re: Very nice of you to write the tl2rpm converter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 01, 2008 at 03:26:57AM +0300, Vasile Gaburici wrote:
> 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.

The tl2rpm is able to produce separate specs per one TeXLive package.
But it would lead to a huge number of packages around 4000 that we
would need to add into Fedora. It is simply not a way to go. So I was
thinking about schemes and collections that could be packaged
separately. The schemes would only be a metapackages dependent on
collections and collections would be sets of packages with one spec
that would cover a particular part of TeX Live (like ConTeXt,
langpacks, etc.) what is actually realizable since it would need about
400 packages.

This looks like an optimal granularity for it since collections
contain largest possible TeX Live bits that don't yet conflicts. But
the review process for 400 generated specs quite scares me.

> 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.

This is "solved" by splitting it into collections.

> 
> 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:

It is expected. Basically the main spec could be a maintainable
template which %includes other specs for %post, %filelist and pakcge
definitions and descriptions what could be automatically generated.
The plan is to only touch the main spec.

> 
> * 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).

Blacklists will be very hard to do since it could break dependencies
generated from the TeX Live metadata.

>   - 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:

I wouldn't package the precompiled TeX Live 2008 binaries. Currently
I'm trying to build them from sources. It is still work in progress.
 
> * 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.

+ optflags we set in Fedora which would get ignored.

> 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...
> >

-- 
Jindrich Novy <jnovy@xxxxxxxxxx>   http://people.redhat.com/jnovy/

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux