TeXLive

[Stephen Montgomery-Smith]

On 10/22/2011 01:18 AM, Hiroki Sato wrote:
> Romain Tartière<romain at freebsd.org>  wrote
>    in<20111011101902.GB14910 at blogreen.org>:
>
> ro>  Hello!
> ro>
> ro>  On Mon, Oct 10, 2011 at 07:23:48AM -0500, Stephen Montgomery-Smith wrote:
> ro>  >  On 10/10/2011 06:44 AM, Eitan Adler wrote:
> ro>  >  >  Are there any plans on getting these committed to the mainline ports
> ro>  >  >  tree? I'd be willing to work with you on that.
> ro>  >
> ro>  >  I agree with Eitan.
> ro>
> ro>  I would also be pleased to see TeXLive in the FreeBSD ports (obviously).
> ro>  There are a few issues to sort out before however:
> ro>    - The way TeXLive sources are distributed is not convenient: all
> ro>      binaries are built and installed from a single sources tarball.
> ro>      This leads to the "big" print/texlive-core but really lacks
> ro>      scalability.  Back in 2008, Hiroki Sato was working on splitting all
> ro>      this AFAICR.  Hiroki, I added you in Cc, can you please tell us if
> ro>      you had any progress on this topic?
>
>   I feel guilty about this because although I had/have several
>   prototypes and plans to integrate TeXLive into the ports tree, it
>   have not actually happened so far.  There were two obstacles in the
>   work.  One was there were technical issues (compatibility-related)
>   that prevented some existing TeX-related software we had in the ports
>   tree from working.  This was in around 2007 but solved now.  Another
>   one was how many ports we should have for TeX-related software.
>   After testing several prototypes including a single port version, a
>   set of ~2000 ports (one port for one macro), ~150 ports, or ~30
>   ports, I think it seems good for us to have one of basic utilities,
>   one for basic (stripped-down) macro sets as something like
>   texlive-core + texlive-texmf, and the others for optional macro
>   packages.  The basic idea is the same among them regardless of the
>   total number of ports.  In practical, 100 would be the maximum
>   number.
>
>   So, primary issues described above were basically solved.  Although
>   there are still trivial issues such as handling of a large distfile,
>   it is not difficult to solve.  However, how to handle updating a
>   macro package in the basic port is a problem to me and time passed
>   when I was thinking about that.  More specifically, currently we have
>   many latex-* and tex-* ports to install new macro packages or
>   override the default ones.  It becomes complex over time.  Committing
>   a single large TeXLive port is easy, but I do not want to create the
>   same situation again in the new world and want consistency for
>   updating a macro package in the distribution.  So, I wanted some
>   compatibility with TeXLive's package management utility (tlmgr).
>   Unfortunately it was too premature when I first looked into it
>   (around 2007, IIRC).  The current version is much better than before,
>   but I still need some investigation about that.  If we have or use
>   reliable package catalogs of CTAN including file lists of each macro
>   package via tlmgr or something, we can take an approach like BSDPAN,
>   I think.
>
>   A version based on TeXLive 2011 with a small number of ports can be
>   committed if we ignore the last concern and clean up the current
>   teTeX-related ports.  Any comments about that?

I wasn't quite sure what you meant by "the last concern."  One concern 
that Romain brings up is that CTAN reroll their tarballs without 
updating the version number.

I really like the idea of a few small texlive ports.  In particular, 
this will really cut down on the invocations of mktexlsr.

But what about this.  Have one TeXlive port that installs installs the 
texlive installer (after building the binaries), and then it runs the 
texlive installer.  The various options that the texlive installer has 
can be passed via config flags of the texlive port.  Then the texlive 
port does a dynamic plist creation by doing a find on 
/usr/local/share/texlive (or whereever it is).  And plist can also 
include an "@unexec rm -rf %P/share/texlive".  plist also includes links 
to the binaries in share/texlive/bin/xxx, so that they will be removed 
upon deinstallation.

The current texlive installer on tug.org is not too bad, but it installs 
pre-made binaries, and on my system xdvi does not work because of 
dynamic library version conflicts.  Also it doesn't delete the links it 
created in bin when it is deinstalled.

The current texlive ports created by Romain have a serious deficiency in 
that tlmgr doesn't work.  And tlmgr is necessary to do things like set 
the page size.

Stephen