The postinstall for tetex (2.0.2-r1) runs texconfig with stdout and stderr piped to /dev/null, but if one of many environment variables is set and in such a way that it might override default configurations, texconfig will print a warning message (invisibly if via ebuild) and then wait for a Return or Ctrl-C to continue. Thus "emerge tetex" appears to hang forever after the "* Configuring teTeX" message, but hitting return about 8 times will allow it to complete. Arguably, having the environment variables set in this way is a user error, but it's relatively easy to do (I have been running TeX for a long time this way without apparent problems), and also easy to fix (see suggested patch below). Reproducible: Always Steps to Reproduce: 1. export TEXINPUTS=/tmp 2. emerge tetex (or if you've already got tetex installed) 3. ebuild /usr/portage/app-text/tetex/tetex-2.0.2-r1.ebuild Below is a patch for the ebuild file that will resolve this issue. diff -upN tetex-2.0.2-r1.ebuild.orig tetex-2.0.2-r1.ebuild --- tetex-2.0.2-r1.ebuild.orig 2003-10-04 10:43:18.000000000 -0700 +++ tetex-2.0.2-r1.ebuild 2003-10-05 13:48:47.000000000 -0700 @@ -159,11 +159,74 @@ pkg_preinst() { einfo "Here I am!" } +check_env_vars() { + fixedvars="" + + ## If user has $fvar environment specifications and these don't + ## contain a double-colon or a leading or trailing colon then + ## they can't be combined with texmf.cnf paths. This is rarely + ## what the user intended, and it will also cause texconfig to + ## generate a warning and wait for a keypress, which will hang + ## this ebuild operation. Instead, patch up the environment + ## variable to allow texconfig to run without hanging and + ## warn the user that we did this in case they wan't to reconfigure + ## later their own way. + + ## The list of environment variables to be concerned with is + ## obtained from the INSTALL document in the tetex distribution. + + for fvar in AFMFONTS BIBINPUTS BSTINPUTS DVILJFONTS DVIPSFONTS \ + DVIPSHEADERS GFFONTS GLYPHFONTS INDEXSTYLE MFBASES MFINPUTS \ + MFPOOL MFTINPUTS MPINPUTS MPMEMS MPPOOL MPSUPPORT OCPINPUTS \ + OFMFONTS OPLFONTS OTPINPUTS OVFFONTS OVPFONTS PKFONTS PSHEADERS \ + T1FONTS T1INPUTS TEXBIB TEXCONFIG TEXDOCS TEXFONTMAPS TEXFONTS \ + TEXFORMATS TEXINDEXSTYLE TEXINPUTS TEXMFCNF TEXMFDBS TEXMFINI \ + TEXPICTS TEXPKS TEXPOOL TEXPSHEADERS TEXSOURCES TFMFONTS TRFONTS \ + VFFONTS XDVIFONTS XDVIVFS ; do + + if test "X${!fvar}" != "X" ; then + + if echo ${!fvar} | grep '::' >/dev/null 2>&1 ; then + : # OK, have a spot in the middle for TEX to insert paths + elif echo ${!fvar} | grep '^:' >/dev/null 2>&1 ; then + : # OK, have a spot at the beginning for TEX to insert paths + elif echo ${!fvar} | grep ':$' >/dev/null 2>&1 ; then + : # OK, have a spot at the end for TEX to insert paths + else + fixedvars="$fixedvars $fvar" + # Add a trailing colon so that default texmf.cnf paths will + # get checked after the user's specifications. + export $fvar=${!fvar}: + fi + fi + done + + ## Make sure that the installation location isn't present as a directory + ## tree base in TEXINPUTS as that will cause errors. + + if test "X$TEXINPUTS" != "X" ; then + if echo $TEXINPUTS | grep /usr/share/texmf// >/dev/null 2>&1 ; then + export TEXINPUTS=`echo $TEXINPUTS | sed -e "s|/usr/share/texmf//||"` + fi + fi + + if test "X$fixedvars" != "X" ; then + ewarn "Added trailing colon to the following environment variables" + ewarn "to allow texconfig to run and append texmf.cfg paths to the" + ewarn "paths in these variables. If this isn't what was desired" + ewarn "please reconfigure tetex after completion of this ebuild." + for fvar in $fixedvars ; do + ewarn "--> $fvar = ${!fvar}" + done + fi +} + pkg_postinst() { if [ $ROOT = "/" ] then einfo "Configuring teTeX..." + check_env_vars mktexlsr &>/dev/null texlinks &>/dev/null texconfig init &>/dev/null
Uhh.. reproduce step #3 above should have a "postinst" at the end of that line. Sorry!
Thanks for your patch, it looks like you've really done some work on this which is great. I, however, would lean to the side of user error on this one, and consider not piping stderr to /dev/null. The patch (while you've done a ton of work) looks complicated, and possibly difficult to maintain (rechecking the ENV list everytime we have an update etc). Is this a more general problem (ie not TeTeX specific) that could affect all/other ebuilds with ENV vars that have been set locally ? if so an eclass, eutils or similar might be the place to put it. Suggestions/Comments?
User error ? Response ?
Sorry... wasn't meaning to ignore comment #2, just never got email indicating there was an update. Yes, this was caused by user error in configuring TeTeX, and I would normally not be inclined to be too worried about that, except that I had been successfully using TeX tools for quite some time despite the user error in the environment variable setting. The only way I became aware of it was the "silent" hanging failures of my "emerge -u tetex" operation. It was the combination of silent hang failures and functional (albeit not correct) configuration that inspired me to submit this bug/patch. The TeTeX tools are all a bit awkward in that they don't handle output redirection and stdio/stderr quite like most tools. If the configuration operation piped stdout to /dev/null but still reported via stderr, that would be helpful, but instead the tex config assumes console interaction and doesn't use stderr for "batch mode" configuration. What I'm getting to is that not piping stdout to /dev/null on the configuration has two drawbacks (IMHO): 1) emerge will still stop while TeTeX config queries the user for help. This is not commensurate with the normal utilization of emerge which runs to completion without further user interaction. 2) texconfig will generate lots of output (ergo the initial /dev/null output redirection) and this can be annoying as well. Problem #2 could be solved by redirecting stdout to something like /var/log/texinstall.log, with an einfo report of that redirection. Problem #1 is more difficult. Without Gentoo-specific modifications to TeTeX itself, the only options I see are the patch I specified below, or possibly an alternative that simply checks for leading/trailing colons or internal double-colons in the various TeX environment variables and ewarns or worse if those are not found. Personally, if you've gone to the work to check for the colons, adding one onto the end is trivial, and is probably what was intended anyhow. Also note that I was surprised myself at the number of environment variables that needed to be considered in the script below. I had initially expected only a couple, but when I researched TeTeX configuration, I obtained the list below. So ultimately, as I see it, this patch addresses incompatibilities between the texconfig interactive-style methodology and the emerge batch-style methodology, as well as addressing some insufficiencies in the former. I agree that the number of environment variables in the patch is a bit daunting, but these are documented in TeTeX, and TeTeX is fairly mature, so I wouldn't expect much perturbation of these in the future, so the complexity is probably fairly "safe". I welcome any responses/discussion on this issue, and again, I apologize for not being aware of the previous comment. I've reopened the bug just to make sure bugzilla notifies you of this added comment... if you disagree with my perspective, feel free to mark it resolved again... I'm not intending to start a "bug war". :)
Now there's what I like to see, proper, informative, well thought out bugzilla comments. Can the output of texconfig conf help us at all ? It complains loudly if one of the environment variables has been set. Unfortunately, requiring TeX to have been built (so we get texconfig) makes this unfeasible to do in pkg_setup() where I would really prefer to do it. Failing that, is it possible to patch the Makefile or similar for the environment variables checking ? Ideally, I'd prefer the merge process discovers if the user has set one (or more) of these variables, report that (and which variables) and exit, leaving the user to unset them him/herself. I certainly agree leaving TeX hanging (at that familiar prompt waiting for response) is not an option, and appreciate your comments on this situation.
Using texconfig output is problematic because it is explicitly an interactive utility; reviewing the source of the script I see no way to run it in "batch" or serial mode. The desire to do this checking in pkg_setup also precludes using texconfig (as noted below) although none of the problems occur until the pkg_postinst phase, so it's not strictly necessary to do it in the pkg_setup phase. Modifying the makefile to do this stuff would involve modifying the standard TeX distribution... I don't develop ebuilds, but I'd imagine this would make release synchronization even more problematic. The patch I proposed is still, IMHO, the best way to approach the problem. As I understand it, there are 3 principle issues regarding the patch: 1) Preferring to do this checking earlier in pkg_setup 2) Number of environment variables involved 3) What is done when an exception is noted. In regards to #1, we could move the patch I proposed to pkg_setup rather than pkg_postinst, but the body of the patch would essentially be unchanged. Also worth noting is that the patch addresses issues that occur in the postinst phase; by moving the checking to the pkg_setup phase it creates artificial prerequisites for earlier ebuild stages which might cause problems for folks performing explicit ebuild stages and intending to do postinst configuration themselves rather than letting ebuild/emerge do it. In regards to #2, I looked at the texconfig script and it maintains the list of environment variables of concern in a script variable, but I don't know of any way to extract that easily from the script without "invoking" the script. The texconfig script has a check_environment function that does the same type of checking as in the patch below, but it still contains "read" operations to get user input and prints stuff to stdout rather than stderr (see previous comment regarding disinclinations to generate too much output). The best I could come up with was to perform the following: $ eval `grep -A9 'envvars=' /usr/bin/texconfig` which ends up setting the envvars variable in the current directory to the same list that texconfig uses. Disadvantages of this include (a) depending on the variable name remaining the same in texconfig, (b) depending on the number of lines of variables not changing. Advantages are (c) the list of variables is taken from the TeTeX distribution rather than being independently maintained in the ebuild file, and (b) if the texconfig does change, the above ebuild statement will fail and will likely be caught before the ebuild is updated/released. In regards to #3, the script below automatically adds the standard TeTeX search paths, which is probably what is wanted when doing a system-level install of TeTeX, and it also generates ewarn statements. The option of showing error messages and exiting was proposed, and that could be done as well, although if that were the case then it would be nicer for the user to find this out in pkg_setup rather than pkg_postinst (or else the error should provide specific instructions on running the "ebuild ... postinst" operation so that they wouldn't have to recompile. Other than these two options, I'm not sure we have many more. OK, as another overall option, I'd be happy to write some Python code instead that would more explicitly parse the texconfig file (there would still be assumptions, but it would be much easier to extract the list of environment variables deterministically in Python than in shell script) and change environment variables/issue warnings/return failure/whatever. If this is preferable to the shell-script patch below, then that's no problem, but it doesn't much change the overall approach to the solution.
No activity here for 1 1/2 years, could someone check this bug?
*** Bug 88738 has been marked as a duplicate of this bug. ***
First note that things has changed since this bug was opened. Now the texmf-update script is the one who calls texconfig(-sys). I am in favor of including the ideas of the proposed patch in the texmf-update script. The only thing that needs considering is what to do if texmf-update findes one of the env. vars set. It could do any of the following: 1. Fail with an error 2. Unset the var 3. Append ":" to the end of it I vote for solution nr. 3, since it is probably what most users want/mean and it doesn't stop a build. Anyone who has a comment about all of this? (I know it is a bit old but still very valid).
I'll cast a vote for solution 3 too.
Created attachment 79440 [details, diff] texmf-update.patch This is a first suggestion to a new texmf-update script for tetex-3. Note that the first two lines in the patch has nothing to do with this issue, but with users who have screwed their system up by changing root's umask (it is okay not to care, but it is an easy fix). The rest just appends ":" to unsafe env. vars. and makes sure /usr/share/texmf and /var/lib/texmf does not appear in TEXINPUTS. Comments?
Added to tetex-3.eclass
