engine setting in context/texexec
Hi Hans and Taco!
I found something interesting, but I couldn't test properly till now:
pdftex 1.40.1 sets engine=pdftex (not pdfetex), but texexec puts created
formats into web2c/pdfetex, so they won't be found as soon as we have
pdftex >= 1.40 around.
Is there a way in texexec to adjust this?
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
Hi Hans and Taco!
I found something interesting, but I couldn't test properly till now:
pdftex 1.40.1 sets engine=pdftex (not pdfetex), but texexec puts created formats into web2c/pdfetex, so they won't be found as soon as we have pdftex >= 1.40 around.
Is there a way in texexec to adjust this?
it may be related to left overs of pdfetex (best remove all traces of pdfetex; in the transition there is indeed this progname stuff going around); i can even imagine (for users) mix ups with progname settings in the cnf file (plain tex) in texexec i've removed all traces of pdfetex (the e) so things should be ok (will test later today on linux since i also want to test the luatex format generation there without the need for lua being installed; looks ok so far) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Mit, 10 Jan 2007, Taco Hoekwater wrote:
in texexec i've removed all traces of pdfetex (the e) so things should
This in itself is a bit problematic, I think. It looks to me like this breaks all installs that only have pdftex 1.30 (because that pdftex is not etex).
I assume that this will happen, yes. I can test it in a few hours on my
home machine if you want to know for sure.
It would be better to check whether we are running < 1.40 or >= 1.40 and
adjust the setting respectively.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
On Mit, 10 Jan 2007, Taco Hoekwater wrote:
in texexec i've removed all traces of pdfetex (the e) so things should
This in itself is a bit problematic, I think. It looks to me like this breaks all installs that only have pdftex 1.30 (because that pdftex is not etex).
I assume that this will happen, yes. I can test it in a few hours on my home machine if you want to know for sure.
It would be better to check whether we are running < 1.40 or >= 1.40 and adjust the setting respectively.
Thanh gave everybody a bit of a headache when he decided to drop "pdfetex" instead of dropping "pdftex". I do not see any easy way of distinguishing an upgraded 1.40 from an old 1.30 installation: spurious "pdfetex" executables are fairly likely even in up-to-date systems, because of pre-installed TeXs. Often upgrades do not delete old stuff properly, and there could also be a visible system-wide tetex or something. Best, Taco
pdftex 1.40.1 sets engine=pdftex (not pdfetex), but texexec puts created formats into web2c/pdfetex, so they won't be found as soon as we have pdftex >= 1.40 around.
Indeed. See the appended email from ntg-context. I don't see how to
fix the problem, except for the symlink hack that I'm doing now.
Several solutions don't work:
1. Remove all traces of pdfetex etc. -- because parallel installations
(e.g. tetex or texlive) might use an older pdf(e)tex and need to
run pdfetex explicitly to get the extensions.
2. Put the formats in web2c/pdftex/ and pass --engine=pdftex to
texexec, because it (last I tested) looks in web2c/pdfetex/ anyway.
So I haven't found anything better than symlinking web2c/pdftex ->
web2c/pdfetex. TL2006 is oblivious to the symlink because it doesn't
use the $engine subpath.
TeX path searching is a nightmare!
-Sanjoy
Date: Wed, 03 Jan 2007 21:08:25 GMT
From: Sanjoy Mahajan
"texexec --make --all" puts the formats in the subdirectory "pdfetex" but I think it should be "pdftex" now.
If 'now' means with pdftex 1.40.0, I think you're right. But that would break context with earlier pdftex's. I've made a symlink from /var/lib/texmf/web2c/pdftex to pdfetex and all is okay now. TexLive2006 works without that hack, because it doesn't put the context formats in an $engine subdirectory, which may cause other problems. See the thread "debian context updates" (Tue, 02 Jan 2007 20:39:40 GMT). -Sanjoy `Not all those who wander are lost.' (J.R.R. Tolkien)
Sanjoy Mahajan wrote:
TeX path searching is a nightmare!
no, it's more that downward compatibility of tex live, tds and kpse is a non-issue (wipe out and install clean policy) personally i think that linux users can best install debian packages and leave tex live for what it is; actually, thinking of it ... since there is room enough on the tex collection dvd, we can put the debian packages on it (also makes a nice historic snapshot) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
personally i think that linux users can best install debian packages and leave tex live for what it is;
I agree 100%. I use the Debian packages plus latest pdftex (with the engine symlink hack), latest metapost, and (give or take a day or two) the latest ConTeXt. Inspired by how easy life became using the packages (versus hacking around in the tetex configuration murk), I rewrote all the Linux installation manpages on the wiki. -Sanjoy `Not all those who wander are lost.' (J.R.R. Tolkien)
On Mit, 10 Jan 2007, Hans Hagen wrote:
TeX path searching is a nightmare!
no, it's more that downward compatibility of tex live, tds and kpse is a non-issue (wipe out and install clean policy)
personally i think that linux users can best install debian packages and leave tex live for what it is; actually, thinking of it ... since there is room enough on the tex collection dvd, we can put the debian packages on it (also makes a nice historic snapshot)
No, you get it up side down!
The problem is not with TeX Live, there we can be sure to have pdftex
1.40.1 and don't care for other things, if there other binaries
installed this is the user problem.
The problem is more with Debian, because for now there is texlive 2005
and I have to keep backward compatibility, and upgrade pathes etc etc.
The problem lies with Debian here.
But we can manage this, but for now we have only 1.30.5 and until tl2006
is in Debian it will take a bit...
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
On Mit, 10 Jan 2007, Hans Hagen wrote:
TeX path searching is a nightmare!
no, it's more that downward compatibility of tex live, tds and kpse is a non-issue (wipe out and install clean policy)
personally i think that linux users can best install debian packages and leave tex live for what it is; actually, thinking of it ... since there is room enough on the tex collection dvd, we can put the debian packages on it (also makes a nice historic snapshot)
No, you get it up side down!
The problem is not with TeX Live, there we can be sure to have pdftex 1.40.1 and don't care for other things, if there other binaries installed this is the user problem.
The problem is more with Debian, because for now there is texlive 2005 and I have to keep backward compatibility, and upgrade pathes etc etc.
well, it depends on the startingpoint ... you (debian) want to take care of previous situations, while tex live assumes no existing installation
The problem lies with Debian here.
But we can manage this, but for now we have only 1.30.5 and until tl2006 is in Debian it will take a bit...
again, you (debian) support the engine subpath while texlive doesn't (while its actually a tds/web2c spec) i dunno the debian policy with installed fonts and such (there are tex users out there with additional (bought) fonts) but that's another area where downward compatibility is not guaranteed (the updmap mess) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Hi Hans! On Mit, 10 Jan 2007, Hans Hagen wrote:
The problem is more with Debian, because for now there is texlive 2005 and I have to keep backward compatibility, and upgrade pathes etc etc.
well, it depends on the startingpoint ... you (debian) want to take care of previous situations, while tex live assumes no existing installation
Well, the problem exists WHEN you take the engine path, because currently in texlive/Debian that would be pdfetex, and in TeX Live upstream pdftex.
But we can manage this, but for now we have only 1.30.5 and until tl2006 is in Debian it will take a bit...
again, you (debian) support the engine subpath while texlive doesn't (while its actually a tds/web2c spec)
We don't support it. I only have it working for context based formats. All other formats go as usual into web2c/.
i dunno the debian policy with installed fonts and such (there are tex users out there with additional (bought) fonts) but that's another area where downward compatibility is not guaranteed (the updmap mess)
There is extensive documentation on this contained in the
tex-common
package: TeX-on-Debian. I myself have quite a lot of commercial fonts
and I do still use the Debian way for local adaptions. The big advantage
here is that even a upgrade of my whole TeX system *still* leaves me
without my commercial fonts, but thery are automatically activated and
included.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Hi, Dropped the CCs because I believe everybody reads dev-context Hans Hagen wrote:
personally i think that linux users can best install debian packages and leave tex live for what it is; actually, thinking of it ... since there
I agree with you (for the subset of users that are linux users, with a debian-based system). For the other linux users, I've been thinking: would it be possible to make rpm packages from the debian packages in an automated fashion, somehow? Meanwhile, we should warn (put on the wiki) that people on a platform that does not have an installed pdftex 1.40 yet, should not attempt to run ctxtools --update. I am thinking MikTeX & MacTeX here. And all context-minimal and gwtex users should update the entire distribution completely. Correct? Best, Taco
For the other linux users, I've been thinking: would it be possible to make rpm packages from the debian packages in an automated fashion, somehow?
From alien(1), which is available on most Debian-based systems:
alien --to-rpm package.deb Convert the package.deb into a package.rpm I've not tried that direction myself, only the other way (just learnt about the --to-rpm switch now). The post-installation scripts might be problematic, because their conversion requires more intelligence than is available in most programs? -Sanjoy `Not all those who wander are lost.' (J.R.R. Tolkien)
On Mit, 10 Jan 2007, Sanjoy Mahajan wrote:
alien --to-rpm package.deb Convert the package.deb into a package.rpm
Better as root alien --scripts --to-rpm ...
The post-installation scripts might be problematic, because their conversion requires more intelligence than is available in most programs?
In fact the post-installation scripts are the big problem since other
distributions don't have update-updmap/language/formats scripts.
All the rest is self-contained.
So, to put it simple: Building a rpm would be trivial. I think I could
do it in 10min. Ok,I could do it 10 years ago when I was working on SuSE
Linux with rpm and I did knew how building rpms are working.
For someone with a bit of rpm knowledge it should be easy to convert the
debian source package to a rpm source package.
If someone steps forward and needs a bit of help, or steps forward to
help me a bit, we can do this and provide rpms at the same time as debs.
But I need someone with rpm knowledge.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Taco Hoekwater wrote:
I am thinking MikTeX & MacTeX here. And all context-minimal and gwtex users should update the entire distribution completely. Correct?
the minimals are less sensitive i'll upload minimals once i have the luatex integration sorted out Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Mit, 10 Jan 2007, Taco Hoekwater wrote:
Meanwhile, we should warn (put on the wiki) that people on a platform that does not have an installed pdftex 1.40 yet, should not attempt to run ctxtools --update.
And this also means that I have to hack around a bit in the context
packages for Debian to make them work with current texlive.
I will see how it works.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
participants (4)
-
Hans Hagen -
Norbert Preining -
Sanjoy Mahajan -
Taco Hoekwater