[tldistro] [tlbuild] patches for TeX Live

[pcpa at mandriva.com.br]

> On Fri, Aug 26, 2011 at 00:45, Karl Berry wrote:
>>
>> Thus, if the distros don't use it, which I don't think they do, there's
>> no use wasting time committing anything there.  My (vague) understanding
>> is that it is more convenient for the distros to download the release
>> tarballs and apply their own fixes, instead of worrying about svn
>> branches.

  For some background information, some month ago, Mandriva was shipping
something like 199x/200x tetex packages in "main", and had a 2007 texlive
random svn checkout in "contrib", somewhat based on the fedora package,
and both packages would conflict, and one would work for some things, and
the other for others...
  Personally, I have close to zero TeX knowledge, but I am considered kind
of an "impossible mission packager" and/or "esoteric problems solver" :-)
and was asked to attempt to work on the package.

  A few days ago Mojca mailed me and asked to join this list and helped
me to solve several problems in the package, so, here I am, after lurking
for a few days...

  Initially, I wrote some perl scripts, that would parse texlive.tlpdb
(btw, there is no such "database" in the tarballs), and would generate
rpm spec files based on it. Ultimately, I gave up on that idea. I still
have it working to some extent, for example:
$ grep %package texlive.spec | wc -l
123
$ grep %package texlive-texmf.spec | wc -l
1996
but I was too afraid of just getting something way too hard to maintain,
and risking all kinds of bugs when having the script to resolve
dependencies, or things like for example, upstream moving files
around and this risking to cause major dependency problems in rpm.
So, my "safe mode solution" was to split it as:

texlive (arch specific)
texlive-texmf (most of texlive-texmf tarball)
texlive-fontsextra (collection fontsextra)
texlive-doc (everything under texmf-dist/doc)
texlive-source (everythong under texmf-dist/source)

  Major source of problems was the fact that almost every "optional"
component of the texlive (and some of the texlive-texmf) tarball already
was packaged, sometimes multiple times in the distro, and I gone in a
process of picking one, using another from the distro, and creating
a not so simple chain of "rpm rules" with Provides/Obsoletes/Conflicts
so that when installing packages, it would automatically remove some,
resolve dependency of anything Require'ing tetex*, and for Conflicts,
usually ask the user to remove or permission to, before installing the
new texlive packages.

  I also made some experiments with providing an alternative of
basically creating a rpm with bits from install-tl-unx.tar.gz
and patching for defaults. But preferred to let it in a way
that if the user wants to install it that way, better to not
"get in the way". And also, this would just potentially create
even more complications for whoever is packaging texlive.

> Yes, distros fetch the *.tar.gz file, but if there was something new
> in branch 20XX, it would be easy to create patchfiles every now and
> then (once per month, when some patches accumulate or when some
> distribution requests patches that they need) and distros could also
> fetch patchfiles from the same location as main tar.gz files.

  I like this idea, and from what I understand from it, could be
something like:

1. A tarball to be installed somewhere like texmf-extra that
   is "hot fixes" for texlive-texmf. texlive-texmf is too big
   of a package to be uploading to mirrors frequently, and
   causing users that do frequent online updates to be
   downloading all the time.
2. More frequent texlive tarballs to recompile arch specific
   bits.

> At least mandriva was willing to apply any patches needed. But if
> there is no reference of what is needed, it is impossible for them to
> decide what else could go in.

  To be sincere, I understand that texlive is very important package,
but I initially did not consider myself as the most appropriate person
to take care of the package, and did not give it the attention it
deserves, for example, not even joining this mailing list before...
But yes, I have interest in knowing of better procedures to keep up
to date with upstream and provide more valuable packages to end users.

> Mojca

Thanks,
Paulo