Bugzilla Bug 246378

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. ***