I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version?
2009/10/25 Neal Becker ndbecker2@gmail.com:
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version?
IMO the latter.
On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version?
I will try to fix it in the texmf.cnf kpathsea configuration file directly in the new TL2009 update.
Jindrich
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jindrich Novy wrote:
On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version?
I will try to fix it in the texmf.cnf kpathsea configuration file directly in the new TL2009 update.
Jindrich
Could you explain? Will you replace the current xdvipdfmx? The current will use kpathsea and will look for config in /usr/share/texmf. I was thinking either:
1) Replace the current xdvipdfmx with the one shipped with texlive
or
2) Use /etc/profile.d to set TEXMFCNF
On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote:
Jindrich Novy wrote:
On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version?
I will try to fix it in the texmf.cnf kpathsea configuration file directly in the new TL2009 update.
Jindrich
Could you explain?
The plan was to update the texmf.cnf to tell kpathsea to look for files in the /usr/share/texmf tree prior to the main TL2009 tree. This should make the utilities like xdvipdfmx work even though they are linked against old kpathsea and expects configuration bits in /usr/share/texmf.
Will you replace the current xdvipdfmx?
Currently I'm trying to not to replace any package that has a separate upstream and is already packaged separatelly in Fedora.
Jindrich
Jindrich Novy wrote:
On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote:
Jindrich Novy wrote:
On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version?
I will try to fix it in the texmf.cnf kpathsea configuration file directly in the new TL2009 update.
Jindrich
Could you explain?
The plan was to update the texmf.cnf to tell kpathsea to look for files in the /usr/share/texmf tree prior to the main TL2009 tree. This should make the utilities like xdvipdfmx work even though they are linked against old kpathsea and expects configuration bits in /usr/share/texmf.
Will you replace the current xdvipdfmx?
Currently I'm trying to not to replace any package that has a separate upstream and is already packaged separatelly in Fedora.
Jindrich
I am maintainer for xdvipdfmx and would be perfectly happy if you adopt it.
Neal Becker wrote:
Jindrich Novy wrote:
On Tue, Oct 27, 2009 at 11:59:30AM -0400, Neal Becker wrote:
Jindrich Novy wrote:
On Sun, Oct 25, 2009 at 03:05:34PM -0400, Neal Becker wrote:
I wonder if texlive should include a /etc/profile.d package to set TEXMFCNF, so that other packages, such as xdvipdfmx will work? Or, should texlive just obsolete xdvipdfmx and include it's own version?
I will try to fix it in the texmf.cnf kpathsea configuration file directly in the new TL2009 update.
Jindrich
Could you explain?
The plan was to update the texmf.cnf to tell kpathsea to look for files in the /usr/share/texmf tree prior to the main TL2009 tree. This should make the utilities like xdvipdfmx work even though they are linked against old kpathsea and expects configuration bits in /usr/share/texmf.
Will you replace the current xdvipdfmx?
Currently I'm trying to not to replace any package that has a separate upstream and is already packaged separatelly in Fedora.
Jindrich
I am maintainer for xdvipdfmx and would be perfectly happy if you adopt it.
s/adopt/obsolete
2009/10/29 Jindrich Novy jnovy@redhat.com:
Currently I'm trying to not to replace any package that has a separate upstream and is already packaged separatelly in Fedora.
IMO I think we'd be better off adopting the texlive versions of the packages, rather than doing a half-and-half job on this by packaging individual upstreams. The reason being that Fedora then benefits from the integration and testing work done by the texlive team. The texlive xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream" release.
J.
On Thursday 29 October 2009 17:26:25 Jonathan Underwood wrote:
IMO I think we'd be better off adopting the texlive versions of the packages, rather than doing a half-and-half job on this by packaging individual upstreams. The reason being that Fedora then benefits from the integration and testing work done by the texlive team. The texlive xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream" release.
J.
I am not sure if Jindrich is talking about this but the same could be said about the other pure latex packages. If the packages are available on texlive they could obsolete the previous versions available on Fedora.
2009/10/29 José Matos jamatos@fc.up.pt:
On Thursday 29 October 2009 17:26:25 Jonathan Underwood wrote:
IMO I think we'd be better off adopting the texlive versions of the packages, rather than doing a half-and-half job on this by packaging individual upstreams. The reason being that Fedora then benefits from the integration and testing work done by the texlive team. The texlive xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream" release.
J.
I am not sure if Jindrich is talking about this but the same could be said about the other pure latex packages. If the packages are available on texlive they could obsolete the previous versions available on Fedora.
Agreed.
On Thu, Oct 29, 2009 at 05:26:25PM +0000, Jonathan Underwood wrote:
2009/10/29 Jindrich Novy jnovy@redhat.com:
Currently I'm trying to not to replace any package that has a separate upstream and is already packaged separatelly in Fedora.
IMO I think we'd be better off adopting the texlive versions of the packages, rather than doing a half-and-half job on this by packaging individual upstreams. The reason being that Fedora then benefits from the integration and testing work done by the texlive team. The texlive xdvipdfmx, for example is (I think), ahead of the 0.4 "upstream" release.
J.
Ok, no problem with obsoleting a Fedora package with a TeX Live variant if you, as a package maintainer of it, wish to. I will add Obsoletes for xdvipdfmx.
I'm presenting a complete list of packages shipped in TeX Live to discuss another possible obsoletions:
dvipdfm dvipdfmx getafm lcdftypetools psutils t1utils xdvi dvipng xdvipdfmx
If you think that also some of these packages in Fedora should be obsoleted, please let me know and I will do so in the next TL repo update.
Thanks, Jindrich
2009/10/30 Jindrich Novy jnovy@redhat.com:
I'm presenting a complete list of packages shipped in TeX Live to discuss another possible obsoletions:
dvipdfm dvipdfmx
I think the latest TeXLive doesn't include dvipdfm as its functionality is now covered by dvipdfmx. Anyway, In both cases I am the packager, and would rather see the texlive variant shipped and the packages obsoleted.
xdvi
Again, would prefer if we obsoleted the separate package and went with the texlive variant. Here however we may need to shipp a separate package for the japanese patched version. Or we could integrate the japanese patch into texlive - this may need some work though, as the japanese patch seems to be unmaintined presently. Longer term I hope xdvi just goes away, as its functionality increasingly gets added to evince - xdvi is only minimally maintained at this point and is rather... crusty.
dvipng
Yep, we should simply go with the texlive version - I am happy with this, as dvipng maintainer.
xdvipdfmx
I'm not primary maintainer of this one, but again, I think we should go with the texlive shipped version (which is ahead of the version available as a separate tarball).
Let me know if you need any help with this.
Cheers, Jonathan
Hi Jonathan,
On Sun, Nov 22, 2009 at 10:30:44PM +0000, Jonathan Underwood wrote:
2009/10/30 Jindrich Novy jnovy@redhat.com:
I'm presenting a complete list of packages shipped in TeX Live to discuss another possible obsoletions:
dvipdfm dvipdfmx
I think the latest TeXLive doesn't include dvipdfm as its functionality is now covered by dvipdfmx. Anyway, In both cases I am the packager, and would rather see the texlive variant shipped and the packages obsoleted.
TeX Live 2009 builds dvipdfm when it is not explicitely disabled. Also collection-basic depends on both dvipdfm and dvipdfmx. So I decided to ship them both.
xdvi
Again, would prefer if we obsoleted the separate package and went with the texlive variant. Here however we may need to shipp a separate package for the japanese patched version. Or we could integrate the japanese patch into texlive - this may need some work though, as the japanese patch seems to be unmaintined presently. Longer term I hope xdvi just goes away, as its functionality increasingly gets added to evince - xdvi is only minimally maintained at this point and is rather... crusty.
I'm not sure about Japanese support here. IIRC Takanori MATSUURA works on this support for TL2009. At this point I would prefer to propose this effort to TL upstream so that we needn't to forwardport these patches too often. I could imagine that Takanori could be official upstream of the new xdvi package providing Japanese support if TL upstream is not against it.
dvipng
Yep, we should simply go with the texlive version - I am happy with this, as dvipng maintainer.
xdvipdfmx
I'm not primary maintainer of this one, but again, I think we should go with the texlive shipped version (which is ahead of the version available as a separate tarball).
Let me know if you need any help with this.
Cheers, Jonathan
At last but not least, all the mentioned packages are obsoleted by their TeX Live variant for some time already in the Fedora repo.
Cheers, Jindrich
-
Jindrich Novy -
Jonathan Underwood -
José Abílio Matos -
Neal Becker