Howdy, new committer here, happy to be on board! For several years I've been using tetex successfully. But as it's no longer updated, I'm happy to move to the new texlive port. It was tricky to install texlive because of tetex (getting tetex deactivated and texlive activated was ugly). But more importantly, now that texlive is installed, there's lots of other ports that still depend on tetex that want to use tetex, such as: $ port deps bibtex2html bibtex2html has build dependencies on: ocaml bibtex2html has runtime dependencies on: teTeX Is there any way that we can have some sort of 'virtual' TeX port that either recognizes tetex or texlive, or otherwise convince ports that depend on tetex that texlive is good enough? JDO
On Jan 9, 2008, at 17:48, John Owens wrote:
For several years I've been using tetex successfully. But as it's no longer updated, I'm happy to move to the new texlive port.
It was tricky to install texlive because of tetex (getting tetex deactivated and texlive activated was ugly).
But more importantly, now that texlive is installed, there's lots of other ports that still depend on tetex that want to use tetex, such as:
$ port deps bibtex2html bibtex2html has build dependencies on: ocaml bibtex2html has runtime dependencies on: teTeX
Is there any way that we can have some sort of 'virtual' TeX port that either recognizes tetex or texlive, or otherwise convince ports that depend on tetex that texlive is good enough?
If more than one port installs a binary foo, and either one is good enough, this could be specified in a portfile by saying depends_lib path:${prefix}/bin/foo:bar where "bar" is the preferred port for providing foo if it is not already installed. The dependencies would have to be changed in all ports that currently depend directly on teTeX.
Ryan Schmidt <ryandesign@...> writes:
If more than one port installs a binary foo, and either one is good enough, this could be specified in a portfile by saying
depends_lib path:${prefix}/bin/foo:bar
where "bar" is the preferred port for providing foo if it is not already installed.
The dependencies would have to be changed in all ports that currently depend directly on teTeX.
OK cool. A few questions then: - At what point do we think about making texlive the 'default' TeX port rather than teTeX? (We should, eventually.) - Seems like it would be more valuable to say "either this port or that port" rather than "depends on file", because there might be many many files that need to be supported. - Let's say I'm updating a port and want to make this change. How can I actually tell what file is the dependency (without delving into the makefiles)? Seems like I'd have to delve. JDO
I hoped someone else would have something to say on the topic, since I myself don't use any of this TeX software. But they haven't so I will. On Jan 9, 2008, at 18:03, John Owens wrote:
Ryan Schmidt <ryandesign@...> writes:
If more than one port installs a binary foo, and either one is good enough, this could be specified in a portfile by saying
depends_lib path:${prefix}/bin/foo:bar
where "bar" is the preferred port for providing foo if it is not already installed.
The dependencies would have to be changed in all ports that currently depend directly on teTeX.
OK cool. A few questions then:
- At what point do we think about making texlive the 'default' TeX port rather than teTeX? (We should, eventually.)
The first thing on the teTeX homepage is a "De-support notice" explaining there will be no further versions. Sounds like now would be a good time. You could contact the maintainers of the teTeX and texlive ports to see if they agree. If they do, then you can contact the maintainers of all the ports that currently declare a dependency on teTeX and work with them to change this to texlive.
- Seems like it would be more valuable to say "either this port or that port" rather than "depends on file", because there might be many many files that need to be supported.
Perhaps. But MacPorts does not currently have any syntax for specifying that, and we've gotten along without it so far. The alternative that we currently have available is to specify that a port depends on a certain file existing, and if it does not, then install one particular port that provides that file. There might be another port (or ports) that could also provide that file, but the user would have to know about this and install that other port first. The dependent port that's specified should be the one that "most" users would want.
- Let's say I'm updating a port and want to make this change. How can I actually tell what file is the dependency (without delving into the makefiles)? Seems like I'd have to delve.
Personally, I would just pick any important file (a binary perhaps, or a library) that both teTeX and texlive provide. I'm not familiar with TeX software, but take perl as an example. We now have ports perl5.8 and perl5.10 which (as far as I know) both install ${prefix}/ bin/perl (and if they don't, then assume they do for the sake of this example). Instead of specifying a dependency on "port:perl5.8" this could be changed to "path:${prefix}/bin/perl:perl5.8". This way, perl5.10's perl is used if it was already installed, and if it wasn't, perl5.8 gets installed.
Ryan Schmidt wrote:
- Let's say I'm updating a port and want to make this change. How can I actually tell what file is the dependency (without delving into the makefiles)? Seems like I'd have to delve.
Personally, I would just pick any important file (a binary perhaps, or a library) that both teTeX and texlive provide. I'm not familiar with TeX software, but take perl as an example. We now have ports perl5.8 and perl5.10 which (as far as I know) both install ${prefix}/bin/perl (and if they don't, then assume they do for the sake of this example). Instead of specifying a dependency on "port:perl5.8" this could be changed to "path:${prefix}/bin/perl:perl5.8". This way, perl5.10's perl is used if it was already installed, and if it wasn't, perl5.8 gets installed.
Not sure if that is a great example. For now, _only_ perl5.8 provides the ${prefix}/bin/perl program and perl5.10 doesn't provide it. Should it follow the lead of python24/python25, where _none_ of the ports supplies ${prefix}/bin/python since r28120, then there wouldn't be *anything* providing a "perl" program (just like with "python", that defaults to using /usr/bin/python - unless the user runs python_select manually for a different version) but only versioned ones like "perl5.8.8" and "perl5.10.0". That this whole situation sucks, as you have to patch each and every #! line to use a versioned interpreter, is a different story... --anders
On 2008-01-11 10:09:21 +0100, Anders F Björklund wrote:
Not sure if that is a great example. For now, _only_ perl5.8 provides the ${prefix}/bin/perl program and perl5.10 doesn't provide it. Should it follow the lead of python24/python25, where _none_ of the ports supplies ${prefix}/bin/python since r28120, then there wouldn't be *anything* providing a "perl" program (just like with "python", that defaults to using /usr/bin/python - unless the user runs python_select manually for a different version) but only versioned ones like "perl5.8.8" and "perl5.10.0". That this whole situation sucks, as you have to patch each and every #! line to use a versioned interpreter, is a different story...
While different python versions are incompatible, different perl versions should be compatible (there are very few backward incompatibilities, but modules based on them should be seen as buggy). So, I'd say that perl5.10 should completely replace perl5.8, i.e. it should provide ${prefix}/bin/perl, and if some modules ever fail with 5.10[*] and the bug can't easily be fixed, then the perl5.8 port could provide a variant without ${prefix}/bin/perl. [*] Also look at reports on CPAN, testers sometimes do wrong things! -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Vincent Lefevre wrote:
While different python versions are incompatible, different perl versions should be compatible (there are very few backward incompatibilities, but modules based on them should be seen as buggy). So, I'd say that perl5.10 should completely replace perl5.8, i.e. it should provide ${prefix}/bin/perl, and if some modules ever fail with 5.10[*] and the bug can't easily be fixed, then the perl5.8 port could provide a variant without ${prefix}/bin/perl.
You are right, although there's a lot of ports that are using "bin:perl:perl5.8" (or port:perl and then ${prefix}/bin/perl) that would probably be surprised when such a change is made... --anders
Citando Ryan Schmidt :
I hoped someone else would have something to say on the topic, since I myself don't use any of this TeX software. But they haven't so I will.
I have something to say.
On Jan 9, 2008, at 18:03, John Owens wrote:
Ryan Schmidt <ryandesign@...> writes:
If more than one port installs a binary foo, and either one is good enough, this could be specified in a portfile by saying
depends_lib path:${prefix}/bin/foo:bar
where "bar" is the preferred port for providing foo if it is not already installed.
The dependencies would have to be changed in all ports that currently depend directly on teTeX.
OK cool. A few questions then:
- At what point do we think about making texlive the 'default' TeX port rather than teTeX? (We should, eventually.)
The first thing on the teTeX homepage is a "De-support notice" explaining there will be no further versions. Sounds like now would be a good time. You could contact the maintainers of the teTeX and texlive ports to see if they agree. If they do, then you can contact the maintainers of all the ports that currently declare a dependency on teTeX and work with them to change this to texlive.
I am the maintainer of the texlive package (with openmaintainer) and since the port exists, the only bugs reported were "does not compile in leopard" (which is now solved) and "a lex file is not understood by macports' lex on ppc" (which was reported and corrected by Simon). So It seems to me texlive *2007* is stable enough. More, it is the same package that is used in openBSD ports and pkgsrc so if there are bugs, they should also occur for them. On the other side, I don't have leopard, my mac is an old powerbook ppc with little ram (and I use it less and less) hence I cannot test deeply this package, neither correct bugs or feature requests*. So I would encourage anybody interested in tex to join in maintainership. Especially when texlive 2008 will appear.
- Seems like it would be more valuable to say "either this port or that port" rather than "depends on file", because there might be many many files that need to be supported.
Perhaps. But MacPorts does not currently have any syntax for specifying that, and we've gotten along without it so far. The alternative that we currently have available is to specify that a port depends on a certain file existing, and if it does not, then install one particular port that provides that file. There might be another port (or ports) that could also provide that file, but the user would have to know about this and install that other port first. The dependent port that's specified should be the one that "most" users would want.
At the moment, what dependent ports will check for is a texmf tree (provided by texlive_texmf-minimal and some binaries (latex, pdflatex, mktexlsr...). So the best dependency scheme would probably be bin:latex:texlive. So that people with tetex who do not care to have the latest distribution can live with teTeX (which works well). I am in favor of replacing dependencies from teTeX to texlive where it is relevant. *: for example build of xetex, xdvipdfmx... xetex is a part of texlive and a distinct port in macports. But I disabled it in texlive as it failed to build and there are reports that the xetex port does not build with texlive... Best regards, Emmanuel
On Jan 14, 2008, at 03:18, Emmanuel Hainry wrote:
If more than one port installs a binary foo, and either one is good enough, this could be specified in a portfile by saying
depends_lib path:${prefix}/bin/foo:bar
where "bar" is the preferred port for providing foo if it is not already installed.
The dependencies would have to be changed in all ports that currently depend directly on teTeX.
- Seems like it would be more valuable to say "either this port or that port" rather than "depends on file", because there might be many many files that need to be supported.
Perhaps. But MacPorts does not currently have any syntax for specifying that, and we've gotten along without it so far. The alternative that we currently have available is to specify that a port depends on a certain file existing, and if it does not, then install one particular port that provides that file. There might be another port (or ports) that could also provide that file, but the user would have to know about this and install that other port first. The dependent port that's specified should be the one that "most" users would want.
At the moment, what dependent ports will check for is a texmf tree (provided by texlive_texmf-minimal and some binaries (latex, pdflatex, mktexlsr...). So the best dependency scheme would probably be bin:latex:texlive. So that people with tetex who do not care to have the latest distribution can live with teTeX (which works well).
Using something like "bin:latex:texlive" is discouraged because a latex binary outside of the MacPorts prefix would satisfy the dependency, but we don't want it to; we only want latex binaries installed by MacPorts to be detected[1]. Therefore, "path:${prefix}/ bin/latex:texlive" should be used instead. [1] http://trac.macosforge.org/projects/macports/wiki/ FAQ#WhyisMacPortsusingitsownlibraries
Citando Ryan Schmidt :
On Jan 14, 2008, at 03:18, Emmanuel Hainry wrote:
At the moment, what dependent ports will check for is a texmf tree (provided by texlive_texmf-minimal and some binaries (latex, pdflatex, mktexlsr...). So the best dependency scheme would probably be bin:latex:texlive. So that people with tetex who do not care to have the latest distribution can live with teTeX (which works well).
Using something like "bin:latex:texlive" is discouraged because a latex binary outside of the MacPorts prefix would satisfy the dependency, but we don't want it to; we only want latex binaries installed by MacPorts to be detected[1]. Therefore, "path:${prefix}/bin/latex:texlive" should be used instead.
I had the impression macports only searched for binaries and libraries in system paths and macports path, which is coherent with it only passing by default include from /usr/include, /usr/local/include and ${prefix}/include (or is it also a mistake on my part?). And since mac Tex distributions install in strange paths (including the architecture of your machine), it should not be found. However you are right that this "path" checking is the safest. Emmanuel
Hi, I just checked which ports are using TeTeX. Quite a few. Nomaintainer: - advi - cfengine - gnustep-make-docs - kdegraphics3 - latex2html - latex2man - lcdf-typetools - maxima - py-pyx - revtex - t1lib - tex-cm-super - tex-fourier-gutenberg - tex-utopia - css@macports.org: doxygen - dan.kelley@dal.ca: gri - eridius@macports.org: caml-pcre - gwright@macports.org: TeXmacs cadabra DoCon breqn lhs2tex - jmpp@macports.org: latex2rtf - jochen@macports.org: gsl - marcuscalhounlopez@mac.com: sml-mode.el - mas@macports.org: mftrace - milosh@macports.org: rubber - minskim@bawi.org: latex-mk - mww@macports.org: tetex-rechnung - pguyot@kallisys.net: dvipdfmx - pguyot@kallisys.net: gnuplot - pguyot@kallisys.net: tex-tipa xdvipdfmx XeTeX - reilles@loria.fr: auxtex - reilles@loria.fr: bibtex2html - stechert@macports.org: octave - tristan@cs.dartmouth.edu: BibTex gtamacfonts - vincent-opdarw@vinc17.org: pari I think the best would be to mail all of them and ask if they can update their port to texlive. The other ports should be tested and then updated to texlive (and maybe also updated). What do you think? Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229
On Jan 14, 2008, at 4:18 AM, Emmanuel Hainry wrote:
I am the maintainer of the texlive package (with openmaintainer) and since the port exists, the only bugs reported were "does not compile in leopard" (which is now solved) and "a lex file is not understood by macports' lex on ppc" (which was reported and corrected by Simon). So It seems to me texlive *2007* is stable enough. More, it is the same package that is used in openBSD ports and pkgsrc so if there are bugs, they should also occur for them.
On the other side, I don't have leopard, my mac is an old powerbook ppc with little ram (and I use it less and less) hence I cannot test deeply this package, neither correct bugs or feature requests*. So I would encourage anybody interested in tex to join in maintainership. Especially when texlive 2008 will appear.
I exercise some of the configurations you don't (leopard, intel, plenty of disk/mips; 10.3, ppc) so I'm happy to help either implicitly through openmaintainer or explicitly. I have considerably less experience when it comes to *TeX innovations of the past 5 years (XeTeX in particular) so it would still be good if someone who exercises the font-heavy side of things were around. Thanks, Eric
Simon Ruderich wrote:
I just checked which ports are using TeTeX. Quite a few.
Nomaintainer: [...]
I've made a patch for those and attached it to ticket #12913. I used the dependency style suggested by Ryan. <https://trac.macosforge.org/projects/macports/ticket/12913> Has someone mailed the maintainers of the other affected ports? Cheers, Josh
On Thu, Jan 17, 2008 at 05:30:12PM +1100, Joshua Root wrote:
I've made a patch for those and attached it to ticket #12913. I used the dependency style suggested by Ryan.
<https://trac.macosforge.org/projects/macports/ticket/12913>
Has someone mailed the maintainers of the other affected ports?
Cheers, Josh
Hi, thanks for your patch. It looks good, but we have to test each port before updating it. I just mailed the maintainers. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229
On Jan 17, 2008, at 1:30 AM, Joshua Root wrote:
I've made a patch for those and attached it to ticket #12913. I used the dependency style suggested by Ryan.
<https://trac.macosforge.org/projects/macports/ticket/12913>
Has someone mailed the maintainers of the other affected ports?
I just tried to get doxygen to build, but something must be haywire with my system. I had a lot of stuff that didn't get properly uninstalled from teTeX, so I'm not sure if that might still be messing things up. I'm not familiar enough with texlive to know where the problems might be. http://trac.macosforge.org/projects/macports/ticket/13986 Any ideas? Chris
participants (10)
-
Anders F Björklund
-
cssdev＠mac.com
-
Emmanuel Hainry
-
Eric Cronin
-
John Owens
-
Joshua Root
-
Paul Guyot
-
Ryan Schmidt
-
Simon Ruderich
-
Vincent Lefevre