texlive + tex4ht

[Jindrich Novy]

On Sat, Dec 15, 2007 at 08:12:05PM +0000, Jonathan Underwood wrote:
> On 15/12/2007, Bryan O'Sullivan <bos at serpentine.com> wrote:
> > Jindrich Novy wrote:
> >
> > > Yes, the rawhide TeXLive doesn't conflict with tex4ht (#411501) any
> > > more (version 2007-2 and on).
> >
> > By the way, someone pointed out that we should be packaging the tex4ht
> > that ships with texlive instead of using the old version.  As the old
> > version of tex4ht seems to produce bad HTML files when used with the
> > texlive packages, I think it's worth a try.
> 
> Well, to clarify, the options are:
> 
> 1) remove the --without-tex4htk when building texlive so that the
> tex4ht binaries get built
> 
> or
> 
> 2) Continue to have an add-on package for tex4ht, which will require
> updating this package.
> 
> This is a case where the Fedora "stick to upstream" doesn't resolve
> the dilemna - on the one hand texlive is an upstream, on the other,
> texlive4ht is an upstream. I do notice that upstream tex4ht has
> updates beyond the version included in texlive. That's true of many
> packages though, and it would be mad to start splitting everything
> out.
> 
> Jindrich's call I guess.
> 
> J.

I vote for 2) generally. Considering that TeXLive is mostly a set of
collections gathered from multiple upstreams at some time, it makes
perfectly sense to separate the most frequently used bits to their own
packages and let them updated/maintained separately by their own separate
maintainers.
The ideal situation IMO would be to have only core TeX/LaTeX bits in the
base TeXLive installation and most of the collections that need to be
updated more frequently than TeXLive release cycle (~once per 2 years)
out of it.
To keep consistency with TeXLive, the main texlive/texlive-texmf
packages could Requires: bits packaged separately as soon as someone
decides to maintain it separately. That would keep the TeXLive
updated, based on users' needs even in the middle of the TeXLive
release cycle.

Any thoughts?

Jindrich

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