#2924 system-texlive

[John Ridgway]

Trees: tested on 10.4, should work on 10.3 and 10.5
Section: text
Validation: built successfully with fink -m --build-as-nobody rebuild

$ fink -v validate main/finkinfo/text/system-texlive.info
Validating package file main/finkinfo/text/system-texlive.info...
Package looks good!
fink -v validate ../../debs/system-texlive_2007-1_darwin-i386.deb
Validating .deb file ../../debs/system-texlive_2007-1_darwin-i386.deb...
Package looks good!

Discussion:
See also the thread in the fink-devel mailing list.

This package allows users to use a separately installed version of TeX Live with fink. TeX Live must be installed in the default location of /usr/local/texlive/2007. This package adds /usr/local/texlive/2007/bin/xxx to the path, where xxx is the appropriate directory for the architecture. This breaks a couple of packages that depend on the TeX binaries being in /sw/bin: luximono and feynmf.

This package is designed to be used in combination with tetex-base-texlive and tetex-texmf-texlive which provide tetex-base and tetex-texmf but are based on texlive. Currently they do not add anything to texlive, but I think they might need to. They are intended only as migration tools.

Because TeX Live does not include libkpathsea.a nor the include/kpathsea this package does not provide kpathsea. This means that the following packages will not work:
ec-fonts-mftraced, ipe6, lcdf-typetools, lilypond, mftrace, ptexenc, pyx-py, tex-guy, vflib3

The following packages will not work because they depend on tetex with specific versions mentioned: doxygen, doxygen1.3, klatexformula, and ptex-texmf.

ha-prosper will not work because it depends on a specific version of prosper

The following packages basically become obsolete, because they are included in the TeX Live distribution:
cm-super, enumitem, ifmslide, jadetex, latex-beamer, latex-figbib, latex-make, pdfscreen, pdfslide, pdfsync, pgf, powerdot, ppower4, prosper, tex4ht, texpower, tipa, unicode-tex, xcolor, xdvi, xetex, and xkeyval

[John Ridgway]

[Jean-François Mertens]

Logged In: YES
user_id=477035
Originator: NO

Sorry won't be able to look at this _ have no texlive installation for the moment.
Somebody else will have to take charge of this _ and ideally dmr should also
have a look at the end..

But a couple of small remarks and questions, just from reading the info:

- pls be careful with the names of the virtual pkgs you create, especially
"texlive" : a real 'texlive' pkg would naturally split into %n, %n-dev and %n-shlibs
(plus a separate %n-texmf). This virtual pkg would prevent this _ most natural _ naming.

Why not just "tex" , or "tex_installation" as the name of the virtual pkg
certyfying that there is whatever tex system installed , and that it is useable by fink ?

- also: it might seem preferable to split the tests for different aspects of tex
into different virtual pkgs (eg, system-tex-bin, system-tex-shlibs, system-tex-dev,
+ a couple of system-texmf pkgs testing the extent of the underlying texmf..)

- system pkgs as here test the functionality is there when they get installed;
but afterwards the user can do whatever he wants, fink is blind to the changes...
virtual pkgs on the other hand (as in VirtPackage.pm) have the advantage to test
for the functionality whenever used.
But this can probably be left for later, in case of need.

- a file %p/texmf.cnf is a no!_no! _ both for fink's policy, and for TeX's TDS ...

- should files not be searched for using kpsewhich etc, rather than hard-coded paths?
(eliminating thus also the need for a number of "Conflicts).
The user should ideally be free to have several coexisting tex-installations _
and even to list each other's texmf trees as additional texmf trees in each texmf.cnf _
and switch between them by just adjusting his PATH (+ MANPATH, etc).
Those virtual pkgs _ and all fink's tex-dependent pkgs _ should then rely on the
fact that the required functionality is there..

JF Mertens

[David R. Morrison]

Logged In: YES
user_id=271216
Originator: NO

The role within fink of "system" packages such as this one is currently under review by the fink core team.

[Andreas Gockel]

The Fink Core Team decided to reject this item, cause we're not interested in interfacing with somebody else's packaging of it.