Spec URL: http://people.redhat.com/jnovy/files/texlive/texlive.spec SRPM URL: http://people.redhat.com/jnovy/files/texlive/texlive-2007-0.2.fc8.src.rpm Description: Binaries for the TeXLive 2007 typesetting system.
*** Bug 242415 has been marked as a duplicate of this bug. ***
Created attachment 158208 [details] end of the rpmbuild output Builid failed here for me (F7, x86_64)
Matej, could you please try it again with the new (0.4) packages: http://people.redhat.com/jnovy/files/texlive/ It should build successfully. Main features/differences from the previous version: 1. dropped former texjive zip list for the texmf trees and texlive now uses the zips generated from the scheme-tetex.tpm from upstream 2. reintroduced texlive-errata updating scheme
1.) Local build works for me (F7, x86_64) 2.) I don't unserstand the advantage of texlive-errata updating scheme?
The new TeXLive binaries package (0.5) is now available again from: http://people.redhat.com/jnovy/files/texlive/ and thanks to cooperation with David Walluck it contains many enhancements: - separated kpathsea from texlive-fonts - applied patches from Debian, SuSE and Mandriva TeXLive distros - TeXLive now links against system freetype2/t1lib - removed kpathsea library building hacks - disabled ttf2pk, so that a dependency on type1 is no more needed - fixed perl requires Jochen, the principle of the texlive-errata scheme is to ship only updated styles to the texmf tree so that the huge texmf package needn't to be pushed as a whole when only a few styles are updated. deltarpm is tricky here as some files are configs/ghosted and frequently modified and so that deltarpm would download the whole package anyway in most cases, therefore the texlive-errata scheme.
Nearly final version 0.6 is now available again from: http://people.redhat.com/jnovy/files/texlive/ It now uses bz2'd texmf tree, which now contains more styles and is more consistent. There was a mistake in generation of style list from tetex in the previous release. The contents of the texmf tree are now close to be final (just in case it is not now) So please have a look at this version and focus on contents. Thanks!
To get i?86 packages, I tried to build version 0.7 of this srpm on FC7. The build finishes during the compilation of xdvik. Relevant log messages are gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -W -Wall -Wunused -I.. -I./.. -DPS_GS -DXSERVER_INFO -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -c help-window.c -o help-window.o help-window.c:43:28: error: X11/Xaw/Paned.h: No such file or directory help-window.c:44:27: error: X11/Xaw/Form.h: No such file or directory etc. The missing files are in libXaw-devel, which is not required. Actually it looks more that "--with-xdvi-x-toolkit=xaw3d" configure switch gets ignored.
Jiri, this is now fixed in the 0.8 version of the texlive packages. xdvi doesn't take into account that the X toolkit could be anything different than Motif or Xaw. There are also available i386 prebuild packages from: http://people.redhat.com/jnovy/files/texlive/
It seems that one or more ruby dependencies are missing. $ texexec --version /usr/bin/env: ruby: Aucun fichier ou répertoire de ce type
(In reply to comment #9) > It seems that one or more ruby dependencies are missing. > > $ texexec --version > /usr/bin/env: ruby: Aucun fichier ou répertoire de ce type When you run $ LANG=C texexec --version there should be an english error message, which would be easier to understand by a lot of people.
I'm sorry. LANG=C texexec --version /usr/bin/env: ruby: No such file or directory
Version of 0.9 is now available via the yum repo for i386 and x86_64: http://people.redhat.com/jnovy/files/texlive/texlive.repo just install it to /etc/yum.repos.d/ and yum install texlive (and texlive-latex). The new packages contain updated xpdf-3.02 from upstream to fix CVE-2007-3387, pdftex no more links statically with libstdc++, xdvi.xaw3d is now part of texlive-xdvi and contains other packaging fixes that mostly affects upgrading from tetex. The new texmf packages contain packaging fixes, it obsoletes tetex-eurofont and tetex-tex4ht as it's part of TeXLive. We can add tetex-eurofont and tetex-tex4ht maintainers to comaintainer list so that they can maintain it in TeXLive if they are interested. License audit is now in progress, currently finished for texlive-texmf and some license changes are discussed upstream.
i386 repo has problems. yum install texlive gives (4/21): texlive-texmf-fon 100% |=========================| 43 MB 01:14 http://people.redhat.com/jnovy/files/texlive/i386/texlive-texmf-fonts-2007-0.9.f c7.noarch.rpm: [Errno -1] Package does not match intended download Trying other mirror. (6/21): texlive-texmf-lat 100% |=========================| 0 B 00:00 http://people.redhat.com/jnovy/files/texlive/i386/texlive-texmf-latex-2007-0.9.f c7.noarch.rpm: [Errno -1] Package does not match intended download Trying other mirror. (21/21): texlive-xdvi-200 100% |=========================| 0 B 00:00 http://people.redhat.com/jnovy/files/texlive/i386/texlive-xdvi-2007-0.9.fc7.i386 .rpm: [Errno -1] Package does not match intended download Trying other mirror.
Ignore comment #13 it works now. Problem is that updmap.cfg file is missing after the update to version 0.9. It seems that this file gets removed by the "%post fonts" scriplet in texlive.spec.
Jiri, it is intentional, I moved updmap.cfg to /etc/texmf/web2c in 0.9, former updmap.cfg was in /usr/share/texmf/web2c, but all system config files belong to /etc hierarchy, the previous spec files assumed that all configuration files has extension .cnf, but there's one exception, updmap.cfg so that all config files were moved to /etc except updmap.cfg. It is now fixed in 0.9.
But there is no updmap.cfg in /etc/texmf/web2c after the update to 0.9, and this looks suspicious to me: %post fonts %{_bindir}/texconfig-sys rehash 2> /dev/null || : /sbin/install-info %{_infodir}/web2c.info.gz %{_infodir}/dir %{__rm} -f %{_texmf_conf}/web2c/updmap.cfg %{__rm} -f %{_texmf_conf}/web2c/updmap.log %{_bindir}/updmap-sys --syncwithtrees > /dev/null 2>&1 || :
There is a conflict with ps2eps. file /usr/bin/bbox from install of texlive-2007-0.9.fc7 conflicts with file from package ps2eps-1.64-2.fc8 file /usr/bin/ps2eps from install of texlive-2007-0.9.fc7 conflicts with file from package ps2eps-1.64-2.fc8 file /usr/share/man/man1/ps2eps.1.gz from install of texlive-2007-0.9.fc7 conflicts with file from package ps2eps-1.64-2.fc8 The standalone packaged ps2eps is more recent. The version of tex4ht bundled in texlive is also old.
I cannot rebuild texlive: $ rpmbuild -bp texlive.spec error: Failed build dependencies: texlive-texmf = 2007 is needed by texlive-2007-0.9.fc8.i386 texlive-texmf-afm = 2007 is needed by texlive-2007-0.9.fc8.i386 texlive-texmf-dvips = 2007 is needed by texlive-2007-0.9.fc8.i386 texlive-texmf-fonts = 2007 is needed by texlive-2007-0.9.fc8.i386 texlive-texmf-latex = 2007 is needed by texlive-2007-0.9.fc8.i386 And then, yum install texlive-texmf texlive-texmf-afm texlive-texmf-dvips texlive-texmf-fonts texlive-texmf-latex ends with: Running rpm_check_debug --> Populating transaction set with selected packages. Please wait. ---> Package texlive-texmf-errata-afm.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-errata-fonts.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-latex.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-errata-latex.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-dvips.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-common.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-errata.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-errata-common.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-fonts.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-errata-dvips.noarch 0:2007-0.9.fc7 set to be updated ---> Package texlive-texmf-afm.noarch 0:2007-0.9.fc7 set to be updated ERROR with rpm_check_debug vs depsolve: Package latex2html needs tetex-latex, this is not available. Package tetex-elsevier needs tetex-latex, this is not available. Package secante_conf needs tetex-latex, this is not available. Package xmltex needs tetex-latex, this is not available. Package jadetex needs tetex-latex >= 3.0, this is not available. Package linuxdoc-tools needs tetex-latex, this is not available. Package tetex-frogg needs tetex-latex, this is not available. Package a2ps needs tetex-latex, this is not available. Package tetex-tex4ht needs tetex-latex, this is not available. Package passivetex needs tetex, this is not available. Package jadetex needs tetex >= 3.0, this is not available. Package jadetex needs tetex >= 3.0, this is not available. Package bibexport needs tetex, this is not available. Package texinfo-tex needs tetex, this is not available. Package a2ps needs tetex-fonts, this is not available. Package tetex-elsevier needs /usr/bin/texhash, this is not available. Package tetex-elsevier needs /usr/bin/texhash, this is not available. Package tetex-frogg needs /usr/bin/texhash, this is not available. Package tetex-frogg needs /usr/bin/texhash, this is not available. Package tetex-tex4ht needs /usr/bin/texhash, this is not available. Package tetex-tex4ht needs /usr/bin/texhash, this is not available. Package bibexport needs /usr/bin/texhash, this is not available. Package bibexport needs /usr/bin/texhash, this is not available. Package latex2html needs tetex-dvips, this is not available. Package docbook-utils-pdf needs tetex-dvips, this is not available. Package tetex-xdvi needs tetex-dvips = 3.0, this is not available. Package a2ps needs tetex-dvips, this is not available. Complete! I am not sure that it is a good idea to have Obsoletes: tetex-afm <= 3.0 Provides: tetex-afm = 3.0 It seems to me that tetex-afm = 3.0 is then provided and obsoleted at the same time, it may be wrong.
In kpathsea-devel the Requires should be: Requires: kpathsea = %{version}-%{release}
I have checked texlive to give an advice about what should be in texlive and what should be outside. In utils/, I think that everything should be outside, except for tpic2pdftex. sam2p, lcdf-typetools seems to me to be interesting packages for fedora, and there is also pdfopen, even though of less interest, but definitely not in texlive. Now, the big part is texk. I didn't had a look at web2c/ since I assume that everything in that directory is part of texlive. For the remaining, I classified in 3 parts. Directories that are rightly in texlive in my opinion and don't have a license issue (as far as I know), directories that are rightly in texlive but have license issues, and last projects that are also outside of texlive and should be maintained separately in my opinion. For the projects that are also out of texlive and should be maintained separately it seems to me that it would be better if you submitted them separately in parallel, but many depend on kpathsea, so can only be approved after texlive. If you don't like that approach I think that the second best would be to leave out the projects that weren't part of tetex and submit them only after texlive has been accepted. Now lets list the projects. I have also put some notes like the licenses in the list. No problem ---------- cjkutils (conv/ Public Domain, hbf2gf/ Public Domain + BSD, scripts/ GPL), dvipos (GPLv2+) lacheck (GPL+), seetexk (is under dvibook on CTAN; MIT and Copyright Only) ttfdump (GPL) contrib (unuseful in unix; GPL and Public Domain) dvidvi, clarified license here (GPL+): http://packages.debian.org/changelogs/pool/main/d/dvidvi/dvidvi_1.0-10/dvidvi.copyright xdvipdfmx(GPL), in XeteX, latest seems to be in texlive gsftopk is in CTAN but it isn't the same than in texlive (changes in the main file), although it is the same latest version. No ChangeLog. MIT. http://math.berkeley.edu/~vojta/gsftopk.html points to CTAN owindvi: xdvi launch script (?) Projects from texlive/CTAN, but with license problem ---------------------------------------------------- texlive: unclear license nts.pl A script refers to context, GPL. Remaining right. tetex: GPL, public domain, LPPL context/texmfstart no license, on http://wiki.contextgarden.net/Read_Me it is said that default is GPL e2pall can certainly be considered Public Domain: # Author: Jody Klymak <jklymak.edu>, publisted by a posting # to the pdftex mailinglist. epstopdf unknown license makeindexk (makeindex) is in CTAN/texlive Classical license, and "All modified versions should be reported back to the author." Said to be Public Domain in ACK, but it certainly means free software. dvips page, without interest. Latest is in texlive: http://www.radicaleye.com/dvips.html Only installed are afm2tfm (Public Domain), dvips and *.lpro. License in dvips.h and hps/*: * This is dvips, a freely redistributable PostScript driver * for dvi files. It is (C) Copyright 1986-2004 by Tomas Rokicki. * You may modify and use this program to your heart's content, * so long as you send modifications to Tomas Rokicki. It can * be included in any distribution, commercial or otherwise, so * long as the banner string defined below is not modified (except * for the version number) and this banner is printed on program * invocation, or can be printed on program invocation with the -? option. Some files are under the GPL. unclear license in tex.lpro tex/*.tex contrib/bbfig/bb.ps contrib/pspic/pspic.sty contrib/psfntmac/ps_*.tex contrib/MakeTeXPK.pl no sell: contrib/timesmat.sty from CTAN/texlive, unclear license for: musixflx ps2pkm dtl ttf2pk. Derived from afm2tfm (dvipsk) and gsftopkk dviljk from CTAN/texlive. Based on dvi2xx in dvi2xx.c * Adapted for the PC: Gustaf Neumann In README dviljk is free software; Gustaf's original files are (I believe) public domain. The files I wrote are covered by the GNU General Public License. xdv2pdf from CTAN/texlive. Common Public License, additions (which ones?) under LICENSE.txt BSD. unknown license for SimplePSInterpreter.h, SimplePSInterpreter.m bibtex8 is from CTAN/texlive: some is GPL, ** The original BibTeX was written by Oren Patashnik using Donald ** Knuth's WEB system. This format produces a PASCAL program for ** execution and a TeX documented version of the source code. This ** program started as a (manual) translation of the WEB source into C. Here is bibtex license (same than TeX) % Copying of this file is authorized only if (1) you are Oren Patashnik, or if % (2) you make absolutely no changes to your copy. (The WEB system provides % for alterations via an auxiliary file; the master file should stay intact.) % See Appendix H of the WEB manual for hints on how to install this program. However I have seen written that this restriction is only when the program name isn't changed. Separate projects ----------------- afm2pl last version in texlive, but separate project http://tex.aanhet.net/afm2pl/ GPL COPYING, based on afm2tfm, copyright without license. chktex seems never installed, it is a distinct project. detex latest version in texlive, but it is a separate project. Unclear license. http://www.cs.purdue.edu/homes/trinkle/detex/ devnag latest version in texlive, but it is a separate project. GPL+. http://devnag.sarovar.org/ xdvik (xdvi) http://sourceforge.net/projects/xdvi read-mapfile.c (getpsinfo() in resident.c) tfmload.c stolen from dvips, These file don't have a copyright notice, the include dvips.h * This is dvips, a freely redistributable PostScript driver * for dvi files. It is (C) Copyright 1986-2004 by Tomas Rokicki. * You may modify and use this program to your heart's content, * so long as you send modifications to Tomas Rokicki. It can * be included in any distribution, commercial or otherwise, so * long as the banner string defined below is not modified (except * for the version number) and this banner is printed on program * invocation, or can be printed on program invocation with the -? option. Mostly MIT + GPL ttf2pt1 latest version not in texlive http://ttf2pt1.sourceforge.net/ see COPYRIGHT (BSD), and BSD-like dvi2tty, old in texlive and non free license in texlive. It is in fact free and it is visible in the latest versions: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424018 http://www.mesa.nl/pub/dvi2tty/ dvipdfm not latest in texlive. Is only for tex distributions, but we qualify as a TeX distribution in that sense. GPLv2+ http://gaspra.kettering.edu/dvipdfm/ dvipdfmx last snapshot more recent, GPLv2+ http://project.ktug.or.kr/dvipdfmx/ dvipng latest in texlive, but it is a separate project: http://savannah.nongnu.org/projects/dvipng/
3 other questions: * how did you generate the xpdf tarball? * why the Build dependencies on texlive-texmf*? There is a comment but I don't understand it * why export LD_LIBRARY_PATH=`pwd`/texk/kpathsea/.libs in %install? Nothing is meant to be compiled at that point. X-Red-Hat-Extra and Application categories shouldn't be added to xdvi.desktop. in install-info scriptlets the .gz should be removed. there is still a comment about using internal freetype, although it seems to be fixed?
Jindrich, is there some interest in building texlive against poppler instead of against the included xpdf. With some copying from debian (unstable) I have managed to do it. There are two ways how to do it. In any case one should modify poppler SRPM to install XPDF headers. This is easy, because poppler has a configure switch to do it. I made these headers to go in a new suppackage, that will be probably usefull only for building TeXlive but anyway. Building TeXlive is then essentially renaming GString to GooString. The only problem is pdftosrc that does not compile. If one decide not to include it in the installation (as debian does now, if I understand it well), the changes to poppler package are really minimal. To include also pdftosrc, one should patch the poppler a little bit more, essentially one should move the definition of class ObjectSteam from XRef.cc to XRef.h. I will attach the second version of patches, both for poppler and texlive, I can provide the first, of course. Hope that it helps.
Created attachment 161796 [details] patch for texlive to compile against poppler
Created attachment 161797 [details] patch for poppler-0.5.91 to include the Xpdf headers.
There is support for external libs for most of the libs in texlive, I have a patch for texlive.spec to use it. The trick is to delete the lib dirs only after running configure. It allows to remove some patches and simplify others. More precisely, I removed texlive-build.patch, modified texlive-pdftex.patch and texlive-ttf2pk-freetype.patch and replaced texlive-xetex.patch by texlive-system_teckit.patch. It doesn't work for teckit as using an external teckit isn't supported, hopefully it will be in next releases.
Created attachment 161799 [details] use support for external libs
Created attachment 161800 [details] modified texlive-ttf2pk-freetype.patch patch to let texlive handle the link
Created attachment 161801 [details] modified texlive-pdftex.patch to let texlive handle the link
Created attachment 161802 [details] patch to use external teckit. Replaces texlive-xetex.patch
texlive-use_xdvi.bin.patch seems to me to be unuseful, the substitution is already performed by configure. Moreover it seems to solve a debian specific issue. Why is there a Requires: flex bison ed It seems to me that lesstif isn't needed. lesstif-devel may be, for the include file Xm/XpmP.h, but X11/xpm.h is used if detected. So I think that there should not be any lesstif related Requires or BuildRequires. I propose a slightly updated texlive-texdoc.patch more fedora centric. The main package should Requires: xdg-utils htmlview
Created attachment 161803 [details] more fedora centric texlive-texdoc.patch
(In reply to comment #21) > 3 other questions: > > * how did you generate the xpdf tarball? Checking the sources out from the TeXLive upstream SVN: svn://tug.org/texlive/trunk/Build/source/libs/ It shouldn't be needed if we manage to compile texlive against poppler. > * why the Build dependencies on texlive-texmf*? There is a comment > but I don't understand it Binary texlive won't build without the main texmf tree. Configure complains: ***************************************************************** * Error: The main texmf tree was not found. * * If you do not have the files, you should be able to them from * * the same place you got these sources from, or from one of the * * CTAN hosts. * ***************************************************************** Winging it. then it tries to use files in $TEXMFMAIN: tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not found. fmtutil: config file `fmtutil.cnf' not found. and ends up with some utilities not build/installed: RPM build errors: File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/amstex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/etex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/lambda File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/lamed File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/pdfetex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/csplain File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/mltex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/pdfcsplain File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/eplain File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/physe File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/phyzzx File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/texsis File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/xelatex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/latex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/pdflatex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/platex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/cslatex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/mllatex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/pdfcslatex File not found: /var/tmp/texlive-2007-0.10.fc8-root-jnovy/usr/bin/pdfplatex > * why > export LD_LIBRARY_PATH=`pwd`/texk/kpathsea/.libs > in %install? Nothing is meant to be compiled at that point. It's useless, so it's now removed. > > X-Red-Hat-Extra and Application categories shouldn't be added > to xdvi.desktop. Removed. > in install-info scriptlets the .gz should be removed. Fixed. > there is still a comment about using internal freetype, although > it seems to be fixed? Yes, it's now fixed. Comment removed.
(In reply to comment #16) > But there is no updmap.cfg in /etc/texmf/web2c after the update to 0.9, and this > looks suspicious to me: > > %post fonts > %{_bindir}/texconfig-sys rehash 2> /dev/null || : > /sbin/install-info %{_infodir}/web2c.info.gz %{_infodir}/dir > %{__rm} -f %{_texmf_conf}/web2c/updmap.cfg > %{__rm} -f %{_texmf_conf}/web2c/updmap.log > %{_bindir}/updmap-sys --syncwithtrees > /dev/null 2>&1 || : Yes, the post scriplet puts updmap.cfg accidentially away. Fixed in 0.10.
Do you agree with this license tag for binary texlive? License: GPLv2 and BSD and Public Domain and LGPLv2+ and GPLv2+ and LPPL
Matthias, could you please have a look at comment #24 ? There's a patch for poppler to include xpdf headers what makes texlive able to build against poppler instead of its internal xpdf. It would be very nice from a texlive POV if this patch is applied.
CCing Kristian, since I am on vacation for the next 2 weeks.
The SRPMs/specs and x86_64 repo is now updated to 0.10, I'll update the i386 repo on monday.
The patch in comment #27 seems to be useless as we don't build ttf2pk.
All repos are now updated to 0.10!
(In reply to comment #32) > > * why the Build dependencies on texlive-texmf*? There is a comment > > but I don't understand it > > Binary texlive won't build without the main texmf tree. Configure complains: > ***************************************************************** > * Error: The main texmf tree was not found. * > * If you do not have the files, you should be able to them from * > * the same place you got these sources from, or from one of the * > * CTAN hosts. * > ***************************************************************** > Winging it. This is not the cause of the failure. The only side effect of the corresponding code is to set texmf, and it is set right with or without installed texlive-texmf. > then it tries to use files in $TEXMFMAIN: > tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not found. > fmtutil: config file `fmtutil.cnf' not found. Here is a serious issue, indeed. > and ends up with some utilities not build/installed: Indeed, that's because mktexlsr and fmtutil-sys fail (and the failure is ignored in the makefile). It may work better with texlive-texmf installed (or tetex), but it is still fundamentaly broken in my opinion, since although the intent of the code (in Makefile.in, after 'temporary fix for missing links') is to use the just built stuff it isn't what happens for 2 reasons. First reason is that kpsewhich is run, so the trick is indeed needed (contrary to what I said earlier): export LD_LIBRARY_PATH=`pwd`/texk/kpathsea/.libs Even with that line uncommented, it is still using installed files and tries to write to installed directories because in build kpsewhich uses in build texmf.cnf which points to /usr/share/texmf/web2c. The only solution I have found is to keep {$SELFAUTOLOC,$SELFAUTODIR,$SELFAUTOPARENT}{,{/share,}/texmf{-local,}/web2c} in front of TEXMFCNF More generally I don't like much the way paths are handled currently. It is a mix with debian patch and sed substitution which in my opinion renders it a bit hard to follow, and moreover it seems to me that it doesn't do exactly the right thing, not only for TEXMFCNF, but only for paths.h. I propose 2 patches. The first one could be sent upstream, it is called texlive-more_paths.patch it adds more paths to be substituted in texmf.in. The other patch is called texlive-fedora_paths.patch and it takes care of substituting the right paths for fedora. paths.h and texmf.cnf are modified. these patches replace texlive-builtin-searchpath-fix.patch texlive-2007-varconfig.patch and the sed substitutions between pushd texk/kpathsea and popd. Now it is clear that these changes aren't of that big importance since they are only for defaults and out-of-FHS use of kpathsea, still I think that it would be better like that. As a side note, I think that using the sed substitutions is better in the case of texlive-texmf, only think is that it should be checked that the result isn't too far from the kpathsea defaults. I will attach a patch for texlive.spec, with the following changes: - change in the kpathsea default paths - don't BuildRequires the *-texmf - ship kpathsea defaults as documentation - simpler handlig of ps2eps I tested a mock build.
Created attachment 161973 [details] mainly correct kpathsea paths and allow for build without texlive-texmf
Created attachment 161974 [details] add more paths for substitution in texmf.in
Created attachment 161975 [details] change default kpathsea paths to be more fedora friendly
The new texlive 0.11 is now uploaded and repodata updated. It newly contains japanese support and fixes/changes proposed by Patrice and others. We should consider this one final IMO.
The licenses issues are blockers, and I also think that the projects I list in Comment #20 under Separate projects ----------------- should not be shipped if they weren't part of tetex previously. And for those that were part of tetex, maybe their subpackage name shouldn't be prefixed by texlive if they have their own subpackage (like xdvi). I have other more minor comments I'll post later.
(In reply to comment #45) > The licenses issues are blockers, Yes, they are, but in the current state of TeXLive packages, which are now in functional state, we should focus on F8 inclusion, because feature freeze was yesterday and we can remove stuff with inappropriate licensing during the last testing period. If TeXLive is not included now into Fedora, there will be *no* TeXLive in it, making F8 terribly poor in comparison with other distros, such as Mandriva or SuSE, where texlive is already included. These license problems can really be resolved after inclusion. > and I also think that > the projects I list in Comment #20 under > > Separate projects > ----------------- > > should not be shipped if they weren't part of tetex previously. Why? One of the criteria needed for TeXLive to be accepted is that it should substitute functionality of tetex, what it does, but why to limit the Fedora TeXLive only to a functionality in obsolete teTeX? This makes no sense to me. > > And for those that were part of tetex, maybe their subpackage name > shouldn't be prefixed by texlive if they have their own subpackage > (like xdvi). > I can add a virtual provides for those packages, but I don't think it's a good idea to remove the texlive- prefix as users should know it is not comming from, say xdvi upstream, but from TeXLive distribution so that it could differ from the official upstream of the projects as the problems users could face should be reportrd to TeXLive upstream.
(In reply to comment #46) > (In reply to comment #45) > > The licenses issues are blockers, > > Yes, they are, but in the current state of TeXLive packages, which are now in > functional state, we should focus on F8 inclusion, because feature freeze was > yesterday and we can remove stuff with inappropriate licensing during the last > testing period. If TeXLive is not included now into Fedora, there will be *no* > TeXLive in it, making F8 terribly poor in comparison with other distros, such as > Mandriva or SuSE, where texlive is already included. These license problems can > really be resolved after inclusion. A package with license issues cannot be approved. Since here we have certainly the same issues in an already included package in Fedora (tetex), it would be acceptable, in my opinion, if you feel that we really are in a hurry. > > and I also think that > > the projects I list in Comment #20 under > > > > Separate projects > > ----------------- > > > > should not be shipped if they weren't part of tetex previously. > > Why? One of the criteria needed for TeXLive to be accepted is that it should > substitute functionality of tetex, what it does, but why to limit the Fedora > TeXLive only to a functionality in obsolete teTeX? This makes no sense to me. The point is not to reduce the functionalities in texlive, but do proper packaging. It is not appropriate to repackage a distribution when it consists of projects that have a clear independence. In general every project with a release distributed and a home page should have its own package. This is evident in the case of texlive because some parts are already out of date. So, to avoid obsoletes and complications, it seems to me that it would be better not to add those to texlive in the first place (and submit those packages separately). There are switches for all the utilities in the texlive configure to avoid building them. As I said above I think that it acceptable to let those that were in tetex slip in, but no more. If there was no tetex in fedora I think that shipping independent projects in texlive would be a blocker. > I can add a virtual provides for those packages, but I don't think it's a good > idea to remove the texlive- prefix as users should know it is not comming from, > say xdvi upstream, but from TeXLive distribution so that it could differ from > the official upstream of the projects as the problems users could face should be > reportrd to TeXLive upstream. My idea was that having those packages from texlive should be only transitory, and to avoid obsoletes/provides and so on and so forth (there are already the tetex related obsoletes) it would be better not to use the texlive prefix in the first place. Especially when the version in texlive is the same than the up-upstream version.
I have checked what was in tetex, this leads to: Independent projects, not in tetex: detex devnag dvi2tty afm2pl dvipdfmx Independent projects, in tetex: dvipdfm dvipng mendex Independent projects, in tetex, consisting of a whole subpackage: xdvik pxdvik
I think that the descriptions could be ameliorated. They are too detailed in my opinion, and at the same time they don't cover what is really in the package. Moreover some packages that are to be installed as dependencies don't need to have such a verbose description. I propose the following, mainly taken from the existing descriptions of course, these are just suggestions: %description TeX Live is an easy way to get up and running with TeX. It provides a comprehensive TeX system. The texlive package contains many binaries and scripts, including tex. Usually, TeX is used in conjunction with a higher level formatting package like LaTeX or PlainTeX, since TeX by itself is not very user-friendly. Install texlive if you want to use the TeX text formatting system. Consider to install texlive-latex (a higher level formatting package which provides an easier-to-use interface for TeX). The TeX documentation is located in the texlive-doc package. %description afm texlive-afm provides afm2tfm, a converter for PostScript font metric files. %description dvips Dvips converts .dvi files to PostScript(TM) format. %description fonts This package contains programs required to generate font files for the TeX system. The kpathsea related programs are also in this package, they are needed in order to find out a file in the TeX file tree. %description latex LaTeX is a front end for the TeX text formatting system. Easier to use than TeX. LaTeX is essentially a set of TeX macros which provide convenient, predefined document formats for users. It also allows to compile LaTeX files directly to PDF format. The TeX documentation is located in the texlive-doc package. %description xdvi Xdvi allows you to preview .dvi files on an X Window System. It seems to me that not removing t1lib is wrong, since reautoconf has already been done: # t1lib: use t1lib.ac and withenable.ac if reautoconf Why not use the external autoconf-2.13? Most the Requires should certainly be %{version}-%{release} That way, if there is a fix that needs to be in 2 dependent subpackages and if the user updates only one of the 2, the other will be dragged in. Obviously not true for the *-errata subpackages, but at least for all the subpackages from the same source package. There is an Obsoletes for tetex-tex4ht remaining. There are BuildRequires within subpackages. This is not wrong, but in my opinion it is easier to follow if all the BuildRequires are in the beginning. You should remove --add-category Application \ disdvi should certainly be in dviutils (if at all in texlive) and I guess it is the same for dvipng. maybe xelatex would better be in texlive-latex? files/directories installed in usr/share/texmf/texconfig are not usefull (except for tcfmgr*), they are only useful when using the dialog from texlive. usr/share/texmf/web2c/*.pool are also in texlive-texmf. and mf.pool is in 2 packages. mkdir -p %{buildroot}%{_texmf_var} is redundant Maybe xetex and context related binaries (and similar in texmf) could be in separate packages, but it is not completely obvious either. What could be interesting, however, would be to group the utilities that are context related and those that are xetex related. Maybe you could use my patch from Comment #28? The timestamps are not kept during install. In general doing make INSTALL='install -p' is sufficient but in that case it may need some testing. Also in the explicit install call of noarch files, you could add -p, like in install -p -m 644 COPYRIGHT ChangeLog %{buildroot}%{_datadir}/texmf/doc/mendexk after the iconv you can use touch -r COPYRIGHT.jis %{buildroot}%{_datadir}/texmf/doc/mendexk/COPYRIGHT.jis I don't think keeping the timestamps that are not easily kept would be a blocker for the review. Maybe %dir %{_texmf_var} could be added too? I haven't checked texlive-texmf*, but I think that there should be something like %dir %{_sysconfdir}/texmf %dir %{_sysconfdir}/texmf/web2c and maybe, if you feel like going through %verify(not md5 size mtime) %config(missingok,noreplace) for the config files that also are in /usr/share/texmf It also seems to me that mktex.opt should be in %{_sysconfdir}/texmf/web2c %config(noreplace). Same for mktexdir.opt vfontmap.sample should certainly be in a doc directory. You could add a proper shebang to texmfstart, or add a Requires: ruby The split between texlive-fonts and texlive is not very obvious to me. For example kpsewhere is in texlive while most of the kpe* programs are in -fonts. Also programs like pfb2pfa tftopl mptopdf and omega related font programs are in texlive while other font related commands are in -fonts. More generally what is the criter to decide that something goes in the font package or the main package? Where should encoding related stuff go? I can implement and test some of my proposals above with a spec file diff if you give me the permission for some of the proposals.
Also i think that it would be better to install the file xdvi48x48.png in %{_datadir}/icons/hicolor/48x48/apps/xdvi.png use in the .desktop file Icon=xdvi And run the appropriate pre/post scripts.
I thought a bit more about the independent packages issue and I think that * packages not in tetex should not be packaged in texlive. detex devnag dvi2tty afm2pl dvipdfmx * packages that are in tetex should be put in their own subpackages (with obsolete for the tetex package they were split off): dvipdfm dvipng mendex * And the subpackages that correspond with independent packages should not have texlive- prependended dvipdfm dvipng mendex xdvik/pdvik Then you can add requires in texlive or texlive-latex for the new subpackages if you think that these subpackages are really needed. That way the packages may be independently submitted to fedora very easily without any renaming/obsolete. Once again I can do patches to the texlive spec file to implement the split.
(In reply to comment #51) > I thought a bit more about the independent packages issue and I think > that > > * packages not in tetex should not be packaged in texlive. > detex devnag dvi2tty afm2pl dvipdfmx I do not agree. For packages which are not currently part of Fedora it would mean extra work to remove them from texlive and add them as separate packages. Of course when someone steps up and submits these packages as separate they can later be removed from texlive. I don't see any problem with that. > * packages that are in tetex should be put in their own subpackages > (with obsolete for the tetex package they were split off): > dvipdfm dvipng mendex You cannot obsolete a package containing N features with a package containing only a single feature from these N features. > * And the subpackages that correspond with independent packages should > not have texlive- prependended > dvipdfm dvipng mendex xdvik/pdvik That's really a matter of personal preference I think. > Then you can add requires in texlive or texlive-latex for the new > subpackages if you think that these subpackages are really needed. > >
(In reply to comment #52) > (In reply to comment #51) > > I thought a bit more about the independent packages issue and I think > > that > > > > * packages not in tetex should not be packaged in texlive. > > detex devnag dvi2tty afm2pl dvipdfmx > I do not agree. For packages which are not currently part of Fedora it would > mean extra work to remove them from texlive and add them as separate packages. > Of course when someone steps up and submits these packages as separate they can > later be removed from texlive. I don't see any problem with that. What extra work? Some of those files have --without, others can simply be removed, and I volunteered to do and test patches. If this is not done now, there will be some extra work when separate packages are submitted with obsoletes and complications. > > * packages that are in tetex should be put in their own subpackages > > (with obsolete for the tetex package they were split off): > > dvipdfm dvipng mendex > You cannot obsolete a package containing N features with a package containing > only a single feature from these N features. That's not the idea. The idea is when foo is split in fooA and fooB, both fooA and fooB obsolete foo, such that on update fooA and fooB get installed. This is what is done, for example in mesa-libGLw: # libGLw used to be in Mesa package in RHL 6.x, 7.[0-2], RHEL 2.1 Obsoletes: Mesa # libGLw moved to XFree86-libs for RHL 7.3, 8, 9, FC1, RHEL 3 Obsoletes: XFree86-libs # libGLw moved to xorg-x11-libs FC[2-4], RHEL4 Obsoletes: xorg-x11-libs > > * And the subpackages that correspond with independent packages should > > not have texlive- prependended > > dvipdfm dvipng mendex xdvik/pdvik > That's really a matter of personal preference I think. Not only it is also a matter of changing more than needed package names and having to add Obsoletes/Provides or not.
Patrice, feel free to post patches to spec to speed things up, I can review, test and apply them quite quickly.
(In reply to comment #54) > Patrice, feel free to post patches to spec to speed things up, I can review, > test and apply them quite quickly. Before I make patch I would like to have your agreement on a specific item. If you dislike one of my proposal it doesn't make sense to make a patch.
(In reply to comment #49) > I think that the descriptions could be ameliorated. > They are too detailed in my opinion, and at the same time > they don't cover what is really in the package. Moreover > some packages that are to be installed as dependencies > don't need to have such a verbose description. I propose > the following, mainly taken from the existing descriptions > of course, these are just suggestions: > > %description > TeX Live is an easy way to get up and running with TeX. > It provides a comprehensive TeX system. The texlive package > contains many binaries and scripts, including tex. > Usually, TeX is used in conjunction with a higher level formatting > package like LaTeX or PlainTeX, since TeX by itself is not very > user-friendly. > > Install texlive if you want to use the TeX text formatting system. Consider > to install texlive-latex (a higher level formatting package which provides > an easier-to-use interface for TeX). > > The TeX documentation is located in the texlive-doc package. Ok, I updated the desription. > > %description afm > texlive-afm provides afm2tfm, a converter for PostScript font metric > files. I let this one more verbose. > %description dvips > Dvips converts .dvi files to PostScript(TM) format. I reduced the description to: "Dvips converts .dvi files produced by the TeX text formatting system to PostScript(TM) format." and let the remaining paragraph intact since it describes useful instalation information. We can tidy it up again as soon as the subpackaging structure of texlive will be clear. > %description fonts > This package contains programs required to generate font files > for the TeX system. The kpathsea related programs are also > in this package, they are needed in order to find out a file > in the TeX file tree. I substituted the original description by yours. > %description latex > LaTeX is a front end for the TeX text formatting system. Easier to > use than TeX. LaTeX is essentially a set of TeX macros which provide > convenient, predefined document formats for users. It also allows to > compile LaTeX files directly to PDF format. > > The TeX documentation is located in the texlive-doc package. Updated. > %description xdvi > Xdvi allows you to preview .dvi files on an X Window System. > > > > > It seems to me that not removing t1lib is wrong, since > reautoconf has already been done: > # t1lib: use t1lib.ac and withenable.ac if reautoconf Fixed. > Why not use the external autoconf-2.13? Why we should? > Most the Requires should certainly be %{version}-%{release} > That way, if there is a fix that needs to be in 2 dependent > subpackages and if the user updates only one of the 2, > the other will be dragged in. Obviously not true for the > *-errata subpackages, but at least for all the subpackages from > the same source package. > > There is an Obsoletes for tetex-tex4ht remaining. Removed. > There are BuildRequires within subpackages. This is not > wrong, but in my opinion it is easier to follow if all > the BuildRequires are in the beginning. I'd let it as is IMO. > You should remove > --add-category Application Removed. > disdvi should certainly be in dviutils (if at all in texlive) > and I guess it is the same for dvipng. > Same probably applies for: %{_bindir}/dvicopy %{_bindir}/dvihp %{_bindir}/dvipdfm %{_bindir}/dvipdft %{_bindir}/dvipng %{_bindir}/dvitomp %{_bindir}/dvitype %{_bindir}/odvicopy %{_bindir}/odvitype %{_bindir}/dvipos I moved them to -dvi and added new %post scriptlet for dvipng.info installation. > maybe xelatex would better be in texlive-latex? Moved. > > files/directories installed in usr/share/texmf/texconfig > are not usefull (except for tcfmgr*), they are only > useful when using the dialog from texlive. Removed. > usr/share/texmf/web2c/*.pool are also in texlive-texmf. > > and mf.pool is in 2 packages. Fixed. > mkdir -p %{buildroot}%{_texmf_var} > is redundant Fixed. > Maybe xetex and context related binaries (and similar in texmf) > could be in separate packages, but it is not completely obvious > either. What could be interesting, however, would be to group > the utilities that are context related and those that are > xetex related. This would need a bit more effort, but seems reasonable. > Maybe you could use my patch from Comment #28? Applied. > The timestamps are not kept during install. In general doing > make INSTALL='install -p' is sufficient but in that case it > may need some testing. I add -p to all install calls. > Also in the explicit install call of noarch files, you could > add -p, like in > install -p -m 644 COPYRIGHT ChangeLog %{buildroot}%{_datadir}/texmf/doc/mendexk > > after the iconv you can use > touch -r COPYRIGHT.jis %{buildroot}%{_datadir}/texmf/doc/mendexk/COPYRIGHT.jis To preserve timestamps? I wouldn't care for these.
The patch in comment #28 was already applied before among the Mandriva patches.
(In reply to comment #56) > > disdvi should certainly be in dviutils (if at all in texlive) > > and I guess it is the same for dvipng. > > > > Same probably applies for: > %{_bindir}/dvicopy > %{_bindir}/dvihp > %{_bindir}/dvipdfm > %{_bindir}/dvipdft > %{_bindir}/dvipng > %{_bindir}/dvitomp > %{_bindir}/dvitype > %{_bindir}/odvicopy > %{_bindir}/odvitype > %{_bindir}/dvipos makempx uses dvitomp, the other seems indeed to better be in dviutils. > I moved them to -dvi and added new %post scriptlet for dvipng.info installation. > > Maybe xetex and context related binaries (and similar in texmf) > > could be in separate packages, but it is not completely obvious > > either. What could be interesting, however, would be to group > > the utilities that are context related and those that are > > xetex related. > > This would need a bit more effort, but seems reasonable. I have just noticed that xetex and xelatex uses dvipdfmx. So taking dvipdfmx from texlive makes sense. Still I think that it would be better to have it in a subpackage, to be able to easily replace it if needed. For the name (with or without texlive-) it isn't an obvious choice: * with texlive it marks that it is not the upstream dvipdfmx * without texlive- it is easier to split and unsplit. I checked that the other utilities I propose to split off are not needed by other scripts or binaries. > To preserve timestamps? I wouldn't care for these. Right. Would be better, in my opinion, but definitively after the import.
(In reply to comment #57) > The patch in comment #28 was already applied before among the Mandriva patches. Indeed, but in comment #28 it is modified (I removed the parts that weren't relevant anymore).
What about the proposal here, http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming that is add virtual Provides to texlive related packages? This is more for post-import, but may be discussed before.
This bug looks like it it is being reviewed by Patrice (or is this an "unofficial review"?), but is currently not ASSIGNED to anybody.
Nobody has signed on to review this package, hence its state. Patrice is offering comments; you are free to do so as well.
(In reply to comment #60) > What about the proposal here, > http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming > > that is add virtual Provides to texlive related packages? > > This is more for post-import, but may be discussed before. Yup, I think the virtual provides for the texlive packages is a good idea, we can add them and tex-foo seems reasonable.
0.12 is now out. The major changes are the legal fixes suggested by Karl Berry, file shuffling between texlive and texlive-fonts package and handful of other fixes. ChangeLog is here: * Thu Aug 30 2007 Jindrich Novy <jnovy> - 2007-0.12 - update description - BR ruby, don't obsolete tetex-tex4ht - remove license problematic/useless stuff, based on email from Karl Berry - move vfont.sample to doc - preserve timestamps - shuffle binaries between texlive and texlive-fonts, update scriptlets
I don't think that mv %{buildroot}%{_texmf_main}/web2c/*.opt %{buildroot}%{_texmf_conf}/web2c/ for file in `ls %{buildroot}%{_texmf_conf}/web2c/ | egrep 'opt$'`; do filename="`basename ${file}`" ln -sf %{_texmf_conf}/web2c/${filename} %{buildroot}%{_texmf_main}/web2c/ done is right. The place where you, as a packager, put config files should be separated from the place where local admins put their config, so I think that symlinking is wrong. Now regarding which files should be under the sole packager ruling (ie in %{_datadir}) and which one should be in %{_sysconfdir}, I think that it should depend on * is it something a user should want to change? if no, then it is for the packager * is there something that is likely to change with releases if yes it should better be for the packager. Based on this I think that the following should go below %{_sysconfig} (and the remaining remain in usr/share/texmf/): texmf/dvipdfm/cid-x.map texmf/web2c/mktexdir.opt They should be %config(noreplace) mktexnam.opt and mktex.opt (contrary to what I said above) should not be in {_sysconfig}, the user in general would better be if he left those under your control. Since you moved kpathsea related programs to main texlive, you should update the %descriptions texhash should certainly be with kpse* binaries. certainly a miss: W: texlive dangling-relative-symlink /usr/bin/ovf2ovp omfonts Maybe one of those isn't in the right package? W: texlive-fonts dangling-relative-symlink /usr/bin/mktexfmt fmtutil I guess that the following are right: W: texlive-latex dangling-relative-symlink /usr/bin/cslatex pdftex W: texlive-latex dangling-relative-symlink /usr/bin/platex ptex W: texlive-latex dangling-relative-symlink /usr/bin/pdfplatex-pl pdftex W: texlive-latex dangling-relative-symlink /usr/bin/platex-pl pdftex W: texlive-latex dangling-relative-symlink /usr/bin/latex pdftex W: texlive-latex dangling-relative-symlink /usr/bin/pdfcslatex pdftex W: texlive-latex dangling-relative-symlink /usr/bin/xelatex xetex W: texlive-latex dangling-relative-symlink /usr/bin/platex209 ptex W: texlive-latex dangling-relative-symlink /usr/bin/mllatex pdftex W: texlive-latex dangling-relative-symlink /usr/share/man/man1/pdflatex.1.gz pdftex.1.gz W: texlive-latex dangling-relative-symlink /usr/bin/pdflatex pdftex Minor issue, there is still a wrong comment about t1lib In the dvips description: * dvips is not only for tex. it is a converter. So I propose for 1st sentetence: Dvips converts .dvi files to PostScript(TM) format. Or, if you want to mention TeX: Dvips converts .dvi files, for example those produced by the TeX text formatting system, to PostScript(TM) format. * I think that texlive-afm is not directly useful with dvips and the mention to texlive-afm should be dropped from dvips. vfontmap.sample should not be in %{_datadir}/texmf/pxdvi, but only in %doc. (or in the texmf doc directory). Regarding the license issues, the files should be removed from the tarball, like explained on http://fedoraproject.org/wiki/Packaging/SourceURL I can do it if you want to. You didn't took Comment #50 into account, do you want a patch? And about splitting subpackages that have a distinct upstream, adding only what was in tetex and not using the texlive- prefix for the packages that should be split, what is your opinion? Just tell me if you like some parts, such that I make a patch.
(In reply to comment #46) > If TeXLive is not included now into Fedora, there will be *no* > TeXLive in it, making F8 terribly poor in comparison > with other distros, such as > Mandriva or SuSE, where texlive is already included. I missed this one... But I think that it is the wrong way to think about packaging in fedora. We are looking for excellence, not for completeness. And we shouldn't lower the quality of our packages to compete with other distros. In general, I find fedora packaging of better quality than in other distros, and I think it is important to keep packages as perfect as possible. Now, this is my vision, and another packager may think otherwise, and also disagree on what would be the right packaging for texlive, and I also know that I can be perfectionist and for those reasons, and others, I haven't assigned that review to me although I made a lot of comments, because I want to leave room for other packagers to approve.
What about using sed instead of perl for the substitutions in mkconf?
(In reply to comment #65) Feel free to send a patch against 0.12 you pointed out in your comment, I'll review it and apply it.
Even the subpackages split without texlive- prefix?
Yes please.
I am currently working on the patch, but I found out that there is no clear dependency between -font and main package, now that kpse* files are in main. In fact the kpathsea executables are sort of low-level utilities for both packages. What about the following: rename the current kpathsea kpathsea-libs add a subpackage name kpathsea holding the kpse* executable and some of the files in %_datadir/texmf/kpathsea?
Created attachment 195671 [details] shell script that can be used to remove non free parts
Created attachment 195691 [details] spec file patch that separates sub packages and remove non free Changelog could be along - subpackage packages that have a distinct upstream - remove non free parts from the archive - install xdvi icon in hicolor directory
I have put the kpse* files back in -fonts (except for kpsewhere). They are needed by the kpathsea internal scripts. You can scratch Comment #71. With this patch I think we are near the end, though I still have 2 concerns: 1. My current understanding of kpathsea is that the library doesn't do a lot by itself, but needs all that is in texlive-fonts. What about a Requires: texlive-fonts in kpathsea? The other possibility would be to have an explicit requires on texlive-fonts by all the packages linking against kpathsea, but it seems to me to be less correct and less easy. 2. The scriptlets seem problematic, since -fonts subpackage uses main package scriptlets in %post. It is not that sure that it is a real issue, though, since maybe rpm makes sure that the main package is installed before running the -fonts post script. Even if things end up being correct, maybe it would be clearer to have fmtutil, texconfig and updmap in -fonts? I have other questions for scriptlets: * why is fmtutil/texconfig init run at install time? Isn't it enough at build time? And same for updmap? * texconfig-sys init already calls fmtutil --all (in %post latex) and updmap calls texhash * why isn't texconfig-sys init also used for the main package? And for dvips (with japanese)? If fmtutil is needed, I think that texlinks and updmap are certainly to be rerun since fmtutil may have changed the links and the maps. If running them once at build time is enough, then you can ignore this point. * I don't think that dviutils needs to call texconfig-sys rehash, nor texlive-latex I also have to check the dependencies between texlive and texlive-texmf to check that the config files are installed in a dependency of the package holding a corresponding script.
A mock build fails in ptex. It seems that it needs ptex.tex min10.tfm which maybe are in the texmf part. I have not fully investigated, but maybe ptex should in a completely separate srpm? It would also simplify a lot the specs.
After a quick look, it looks like ptex can only be build within a full web2c build. This could be a reason for reintroducing the dependency on the texmf package. Another possibility could be to install only the needed files in a place where they would be searched for during the build. Another possibility could be to drop the ptex support since it should really be integrated upstream and not in fedora. The debian solution is to add a package with stripped down tetex sources. This is also possible, but a fair amount of work. Another possibility would be to package ptex separately, with the main texlive source, and only build ptex in this srpm. This seems to me to be the cleanest way, in fact.
0.13 is out! main changes are: * Wed Sep 19 2007 Jindrich Novy <jnovy> - 2007-0.13 - update ls-Rs to deal with the japanese support - update ptex to 3.1.10 and mendex to 2.6e - fix install-info in scriptlets * Tue Sep 18 2007 Patrice Dumas <pertusus> - subpackage packages that have a distinct upstream - remove non free parts from the archive - install xdvi icon in hicolor directory
There is a circular build dependency when texlive depends on texlive-texmf. texlive build -> texlive-texmf -> texlive command for %post It should really be avoided.
The packages in the repo do not properly obsolete/provide virtual tetex provides needed for upgrading from tetex to texlive components: ERROR with rpm_check_debug vs depsolve: Package tetex-latex needs tetex-dvips = 3.0, this is not available. Package tetex-xdvi needs tetex-dvips = 3.0, this is not available. Package tetex-latex needs tetex = 3.0, this is not available. This was on F7/x86_64.
Yes, there is: Obsoletes: tetex-latex <= 3.0 Provides: tetex-latex = 3.1 is the spec file, because it wouldn't be otherwise clear which package to install if both tetex and texlive provides, say, tetex-latex = 3.0, so texlive provides 3.1, newer version.
So the 0.15 is now out. The most important news are: - fix t1lib flaw CVE-2007-4033 (#352271) - fix CVE-2007-4352 CVE-2007-5392 CVE-2007-5393, various xpdf flaws (#345121) - xdvi won't segfault if DVI file contains character which is not present in font (#243630) - fix dvips -z buffer overflow with long href (#368591) - fix insecure usage of temporary file in dviljk (#368611, #368641) - link against poppler, not internal xpdf - include arabtex It reads that TeXLive now links against poppler (thanks to Jiri Cerny), arabtex is included and some pending security issues are fixed. The new poppler is now part of my texlive repository until it's applied in fedora (bug 403211). If you want to fix something, please send patches! Thanks!
This package seems acceptable to me except for 2 things: 1. the kpathsea library in fact call the kpse* executables, so I think there should be, for kpathsea: Requires: texlive-fonts 2. there is a real issue regarding installation order/postscripts run order. I didn't get a lot of responses on fedora-devel-list: https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00488.html The issue with postscripts order is that (for example) updmap-sys should be run only after texlive, texlive-texmf, texlive-fonts, texlive-texmf-fonts and kpathsea have been installed, though I am not sure that it is what happens.
2 minor comments, not blockers: The Requires: poppler is not needed since the poppler soname is rightly taken. htmlview is deprecated and should be replaced by xdg-open only. Both issues can be fixed after the import.
All you noted except postscript order is now fixed in 0.16, which I just uploaded. Since this version of TeXLive is now linked against poppler and the patched version of it is now applied in rawhide I think nothing hinders TeXLive inclusion to rawhide. After that we could have basic infrastructure like bugzilla for texlive component which is desperately needed. Tracking multiple issues in this single bugreport is a pain for me.
Yes, you are right. APPROVED! It will be easier to find out the post script issues with the package in rawhide.
New Package CVS Request ======================= Package Name: texlive Short Description: Binaries for the TeX formatting system Owners: jnovy Branches: InitialCC: Cvsextras Commits: yes
Successfully built, closing. Thanks for cooperation!
Would someone comment on the following thread? https://www.redhat.com/archives/fedora-packaging/2008-January/msg00002.html I questioned about "release of subpackage with version different from main rpm" and the answer was generally this should not occur.
(In reply to comment #88) > Would someone comment on the following thread? > https://www.redhat.com/archives/fedora-packaging/2008-January/msg00002.html > > I questioned about "release of subpackage with version different from main rpm" > and the answer was generally this should not occur. In general, yes, but for texlive it makes sense. Texlive is a bit like perl in that it is more than a single package, but a distribution. I think that some subpackages should be completly out of texlive (see above), but some will anyway stay in texlive, and for the others we are waiting for review requests.