[XeTeX] How to manually create the xelatex.fmt?

[Chris Travers]

A few thoughts here as to where I think solutions lie.

On Wed, Oct 19, 2011 at 12:53 AM, Ulrike Fischer <news3 at nililand.de> wrote:

> The problem is that there seems to a mounting number on Linux users
> which are reluctant to install software without using there package
> manager. And there seems to be a mounting number of  maintainers of
> linux distros (there just was a quite heated discussion in d.c.t.t.)
> which enforce this reluctance by telling people that they set their
> system at risk if they install e.g. a new TeXLive without using the
> disto package manager.
>
> On the other side the linux distros seems to be either unwilling or
> unable to update the packages they support. Your list is quite
> impressing in this respect:
>
>
>> Debian Lenny:  TexLive 2007
>> Debian Squeeze:  TexLive 2009
>> Debian Sid:  TexLive 2009
>> Ubuntu 10.04 LTS:  TexLive 2009
>> Red Hat Enterprise 6:  TexLive 2007
>> That means that the most recent versions of CentOS and Scientific
>> Linux also use 2007.
>
> This is all (partly horribly) outdated. The current TeXLive version
> is 2011 and they are currently working on 2012.


And obviously this puts a lot us in bad positions.  If RHEL 6
(released about a year ago) is sticking to TeXLive 2007, we all have
problems.  The question is what the community can reasonably do, and
what developers can be expected to do navigating these issues.

Obviously developers who want to accommodate the users who are
unwilling to install software outside their package manager will need
to make some choices in order to do so.

On the other a very short support cycle doesn't give sufficient time
for packages to make it through the packaging and testing processes
and thus be considered in time, so I think this means some compromises
on all sides to some extent.

So here are some expectations on all sides that I think are
reasonable, that I suspect perhaps with some modifications, might help
us all out.

1)  Package maintainers for distros should be the point of contact for
bug reports for their packages.  Even in the best of circumstances
there is a lag between the release of a bug fix and when it gets into
a repo.  I know I have filed my share of bug reports for Fedora
packages (including Fedora TeXLive packages).

2)  Developers of higher-stack applications who use distro packages
(like myself) are going to have to content ourselves with stable
subsets of functionality.  There are no two ways about it.  The
templates LedgerSMB ships with are not going to be fancy.    Bugs will
be expected to be worked around rather than reported to the
developers, and if they are reported it's to the package managers.

3)  Finally, I don't think it's too much to ask that time-based
warnings (as I ran into) trigger warnings in the software rather than
disabling it.  This isn't a bug report yet btw because I haven't been
able to verify it against up to date versions yet.  I also think a
reasonable response to many issues is "this has been fixed in more
recent versions, here's a work around" if people care to volunteer.
>
> As the maintainer of the KOMA-packages pointed out this makes
> support rather difficult: He constantly gets reports about bugs
> which have been resolved years ago.

Heck, I get that with LedgerSMB :-P.

>
> What would you think of a linux distro which would force you to use
> a virus protection software with signature files five years old?
>
I wouldn't think much of a linux distro that asked me to use virus
protection software.....  So maybe not the best example.  And moreover
we aren't talking about the signature files are we, here?  We're
talking about core utilities which are essentially disabled after five
years.  If I verify it on TeXLive 2011, I'll report it as a bug.
Until then it's a serious annoyance with an older version.
>
>
>> However, the software project has contributors on both TexLive 2007
>> and 2009, and so our coverage in terms of testing is pretty good
>> there.
>
> 2009 is outdated. As you could see from the answers here quite a lot
> people did install texlive 2011.
>
Maybe, but these are the two that most distros probably are going to
come with.  Yes, it's possible to update to 2011 on Fedora using RPMs
but generally accounting software we like to put on long term support
versions, which means Debian Stable, Ubuntu LTS, and RHEL (and
friends).  Generally speaking many of my clients may have requirements
that their operating systems are currently supported (for example, due
to credit card security requirements, such as the PCI-DSS), and the
like.  Ensuring that things are running supported versions is a
concern and something that frequently is easiest to demonstrate when
using a long-term support distro and the package manager.

So.......  Where does that leave everything?  With a big mess, naturally.

However, it's perfectly reasonable that Debian Stable will be out of
date by a few years, as it is with every other LTS distro out there.
I think you have to figure that by the time the distro is released, it
will be out of date by at least a year, and the distro will probably
be planning on supporting it for another 5-6 (For example RedHat
supports versions of PostgreSQL that are up to 7 years old,
backporting security fixes from newer ones).  Obviously things are
more dire than that with RHEL 6 and TexLive.......

Best Wishes,
Chris Travers