In this section --- In that case, you will have to check which language.dat file is being used: Code Listing 4.6: find language.dat $ kpsewhich language.dat /usr/share/texmf/tex/generic/config/language.dat --- There is a gross failure to mention the following information: ls /etc/texmf/language.d*/ /etc/texmf/language.dat.d/: language.texlive-langukenglish.dat /etc/texmf/language.def.d/: language.texlive-langukenglish.def Initially, I had rouge files in there from other packages, and they were causing all my ebuilds ( texlive-latex, texlive-omega ) to fail mid build looking for hyphenation files. This appeared to make no coherent sence when the problem persisted after removing the entirety of texlive and almost causing serious harm to my system ( the serious harm deal was my fault mostly, but still rather frustrating ) It needs to be stated, that if there are files in *THOSE* directories and their corresponding ebuilds are absent, *THERE WILL BE PROBLEMS* ( kpsewhich conveniently does not know of those files )
Documents in /proj/ belong to that particular project. Not our problem; reassigning.
(In reply to comment #0) > There is a gross failure to mention the following information: > > ls /etc/texmf/language.d*/ > /etc/texmf/language.dat.d/: > language.texlive-langukenglish.dat > > /etc/texmf/language.def.d/: > language.texlive-langukenglish.def This is only for texlive 2008 > It needs to be stated, that if there are files in *THOSE* directories and their > corresponding ebuilds are absent, *THERE WILL BE PROBLEMS* so you're suggesting to add a note about the language.d* layout for tl 2008, right ?
(In reply to comment #2) > > This is only for texlive 2008 > > so you're suggesting to add a note about the language.d* layout for tl 2008, > right ? > More or less. If not in the tex-live-2007 -> 2008 migration guide, then it should be on virtually every ebuild that is affected by this. ( latex/omega/lang* ) Its not a behavioural bug, because its fairly standard to leave config files behind afterwards, its just a lack of functionality problem. One could argue this is a problem with the build process that what will be compiled is not something thats controllable by portage directly, or that there should be some checks in place for these files and their missing corresponding packages to warn the user of things that wont work, but by far the simplest solutions are to document the problem clearly in a common place. alternatively, these language files could be forced into an out-of-search path folder and then turned on with some eselect tool, but that's getting a bit hairy with "ok, you've enabled this, time to go and recompile all texlive,... but sorry, we don't know what exactly needs to be redone because we cant see untill we try and it fails" Documentation is really the simplest solution :)
(In reply to comment #3) > (In reply to comment #2) > > > > This is only for texlive 2008 > > > > so you're suggesting to add a note about the language.d* layout for tl 2008, > > right ? > > > > More or less. If not in the tex-live-2007 -> 2008 migration guide, then it > should be on virtually every ebuild that is affected by this. There will most likely be no 2007->2008 migration guide as it should be smooth. > One could argue this is a problem with the build process that what will be > compiled is not something thats controllable by portage directly, or that there > should be some checks in place for these files and their missing corresponding > packages to warn the user of things that wont work, but by far the simplest > solutions are to document the problem clearly in a common place. It's a problem to have wrong config files, the same as it is to put -iwannafail in your cflags or to break your gcc spec file: that'll make the build process abort. > alternatively, these language files could be forced into an out-of-search path > folder what is an out of search path ? the language.d{at,ef} files are generated by texmf-update > and then turned on with some eselect tool I don't think that's worth it: just install or not the corresponding language support package. And doing it the eselect way will cause more problems than it solves, think about some package having a german documentation; that'll require the german support files to be installed *and* the support to be enabled. The latter will most likely cause problems. > hairy with "ok, you've enabled this, time to go and recompile all texlive,... > but sorry, we don't know what exactly needs to be redone because we cant see > untill we try and it fails" We do know: the formats. Note that we are not forced to compile them in the ebuild because texmf-update does it; but that allows to catch such issues while installing instead of installing the file and hoping they won't fail; if they do fail your (la)tex install won't work and you'll have great pain identifying the problem.
> It's a problem to have wrong config files, the same as it is to put -iwannafail > in your cflags or to break your gcc spec file: that'll make the build process > abort. Quite, but to break GCC flags I have to intentionally perform an action that is stating my behavioral intent. These config files however, I didn't even notice existed until I happened to see them mentioned in the CONTENTS list of one of the ebuilds i was toying with trying to diagnose the problem, and decided to take a poke. This is automagic automated system breakage, not entirely cool. > > alternatively, these language files could be forced into an out-of-search path > > folder > > what is an out of search path ? > the language.d{at,ef} files are generated by texmf-update > > > and then turned on with some eselect tool > > I don't think that's worth it: just install or not the corresponding language > support package. And doing it the eselect way will cause more problems than it > solves, think about some package having a german documentation; that'll require > the german support files to be installed *and* the support to be enabled. The > latter will most likely cause problems. Yeah, I agree, the more you try putting code in there to solve the problem the more problems you'll have to solve ;) > > hairy with "ok, you've enabled this, time to go and recompile all texlive,... > > but sorry, we don't know what exactly needs to be redone because we cant see > > untill we try and it fails" > > We do know: the formats. > Note that we are not forced to compile them in the ebuild because texmf-update > does it; but that allows to catch such issues while installing instead of > installing the file and hoping they won't fail; if they do fail your (la)tex > install won't work and you'll have great pain identifying the problem. The problem appears that, the lang* ebuilds can be removed, and upon removal, their effect is not obvious until much later ( as there's no dependency checking done to make it work ) And also, upon removal, it nowhere states "ok, next time you build latex it will die unless you remove these config files, that you don't even know about, but we put there" 1) install texlive-langgreek 2) install texlive-latex *all is good* 3) uninstall texlive-langgreek 4) install texlive-latex *everything dies* 5) ls -la /usr/share/texmf/tex/generic/config/ total 32 drwxr-xr-x 2 root root 4096 Nov 13 00:09 . drwxr-xr-x 6 root root 64 Nov 11 20:49 .. -rw-r--r-- 1 root root 2332 Nov 13 00:10 language.dat -rw-r--r-- 1 root root 1762 Nov 13 00:10 language.def -rw-r--r-- 1 root root 2159 Nov 11 20:48 language.us -rw-r--r-- 1 root root 1218 Nov 11 20:48 language.us.def -rw-r--r-- 1 root root 2102 Nov 13 00:09 pdftex-dvi.tex -rw-r--r-- 1 root root 284 Nov 13 00:09 pdftexconfig.tex 6) 'This file is automatically generated by texmf-update' 7) "So you should check that there are no other language.*.dat files in that directory other than the ones installed by the various dev-texlive/texlive-lang* ebuilds" [[ CHECK ]] 8) "corrupt language.def? rebuild it!" 9) rm /usr/share/texmf/tex/generic/config/language.dat texmf-update 10) install texlive-latex 11) It dies <-- here is the point you go "wtf" and conclude documentation is wrong. 12) ls /etc/texmf/language.d* /etc/texmf/language.dat.d: language.texlive-langgreek.dat language.texlive-langukenglish.dat /etc/texmf/language.def.d: language.texlive-langgreek.def language.texlive-langukenglish.def 13) rm /etc/texmf/language.d*/language.texlive-langgreek.* 14) install texlive-latex *works* 15) <-- here is the point you go and file a bug :) The solution to me at least seems to put a warning in at stage 3, and provide a way to check for probable causes of failure to build, at or before stage 4. Granted, this wont solve the problem of people removing the language file and then wondering why it doesn't work in their personal files, but they probably actually *want* those language files, as opposed to me whom removed them because he wasn't using them, and nothing 'depended' on them. Said people will of course simply start by reinstalling the packages concerned, at which point they hope the reinstallation solves the problem. Of course, if you remove one language file, thinking you don't need it, and install another, latex will still fail to build and it really wont be obvious.
(In reply to comment #5) > And also, upon removal, it nowhere states "ok, next time you build latex it > will die unless you remove these config files, that you don't even know about, > but we put there" > > 1) install texlive-langgreek > 2) install texlive-latex > *all is good* > 3) uninstall texlive-langgreek > 4) install texlive-latex > *everything dies* its fine here > 5) ls -la /usr/share/texmf/tex/generic/config/ > total 32 > drwxr-xr-x 2 root root 4096 Nov 13 00:09 . > drwxr-xr-x 6 root root 64 Nov 11 20:49 .. > -rw-r--r-- 1 root root 2332 Nov 13 00:10 language.dat > -rw-r--r-- 1 root root 1762 Nov 13 00:10 language.def > -rw-r--r-- 1 root root 2159 Nov 11 20:48 language.us > -rw-r--r-- 1 root root 1218 Nov 11 20:48 language.us.def > -rw-r--r-- 1 root root 2102 Nov 13 00:09 pdftex-dvi.tex > -rw-r--r-- 1 root root 284 Nov 13 00:09 pdftexconfig.tex yes there should be a note in the doc for this difference with 2008 > 12) ls /etc/texmf/language.d* > /etc/texmf/language.dat.d: > language.texlive-langgreek.dat language.texlive-langukenglish.dat > > /etc/texmf/language.def.d: > language.texlive-langgreek.def language.texlive-langukenglish.def weird; it gets removed here... probably I should add those dirs to config_protect_mask > Granted, this wont solve the problem of people removing the language file and > then wondering why it doesn't work in their personal files, but they probably > actually *want* those language files, as opposed to me whom removed them > because he wasn't using them, and nothing 'depended' on them. Anyway, it shouldn't allow it to break when removing some language support.
(In reply to comment #6) > > 5) ls -la /usr/share/texmf/tex/generic/config/ > > total 32 > > drwxr-xr-x 2 root root 4096 Nov 13 00:09 . > > drwxr-xr-x 6 root root 64 Nov 11 20:49 .. > > -rw-r--r-- 1 root root 2332 Nov 13 00:10 language.dat > > -rw-r--r-- 1 root root 1762 Nov 13 00:10 language.def > > -rw-r--r-- 1 root root 2159 Nov 11 20:48 language.us > > -rw-r--r-- 1 root root 1218 Nov 11 20:48 language.us.def > > -rw-r--r-- 1 root root 2102 Nov 13 00:09 pdftex-dvi.tex > > -rw-r--r-- 1 root root 284 Nov 13 00:09 pdftexconfig.tex > > yes there should be a note in the doc for this difference with 2008 done > > 12) ls /etc/texmf/language.d* > > /etc/texmf/language.dat.d: > > language.texlive-langgreek.dat language.texlive-langukenglish.dat > > > > /etc/texmf/language.def.d: > > language.texlive-langgreek.def language.texlive-langukenglish.def > > > weird; it gets removed here... probably I should add those dirs to > config_protect_mask and done too -> fixed
*** Bug 288724 has been marked as a duplicate of this bug. ***
