[tex-live] textlive seems to ignore top of home tree

[hometreetexlive.9.virgilinux at dfgh.net]

Manuel Pégourié-Gonnard - mpg at elzevir.fr wrote:
>Le 21/07/2010 15:19, hometreetexlive.9.virgilinux at dfgh.net a écrit :
> >Well, just following Akira's suggestion I achieved 
>> the exact functionality
>> that is being proposed with one single line of "code"
>> (export TEXINPUTS=/home/rodxxx/texmf: )
>> ...
>
>Btw, maybe it would be better the other way round: 
>looking first at the "regular" location, then at the root of the tree:
>
> export TEXINPUTS=:/home/rodxxx/texmf

Completely agree.  I made the change and it seems to work as expected... if there is an instance of a given file at the top and in the subdirectory, kpsewhich points to the instance in the subdirectory. But if the only instance is at the top, kpsewhich still finds it. I think exactly that would be the ideal default behaviour.

>> I myself cannot notice any performance difference while doing 
>> simple tests of this action. Then again, if I had a million items at
>> the top of the home tree then there may be a performance hit... 
>> but I cannot imagine.. any user having a huge number of items in the
>> HOME tree...

> Trust me (and Karl, and others), some users *do* have 
> a huge number of files in TEXMFHOME. 
> Reality is sometimes counter-intuitive, at least if your intuition 
> is not regularly fed with a lot of surprising examples 
> of how people use TeX.

There may well be some users with huge TEXMFHOME. But still one has to consider:

(a) the percentage of those users in the total user base

(b) the typical "proficiency" of such users (vs the average user)... Power users are likely to be over-represented among such users -- those with huge TEXMFHOME. 

(c) A decrease in performance, while undesirable, it is a relatively mild problem (within reason) in the sense that the user is able to continue to get the job done (even if not as fast as s/he would like to)... Under most scenarios it would be non-emergency... the user could without a lot of pressure seek help to determine why the system seems to run slower than expected and eventually figure out what may be wrong. On the other hand, a condition such as "class not found" stops the user from accomplishing any usable work, and may have severe consequences under certain scenarios (missing an important deadline, perhaps?). Thus, it would seem that the priority should go to the latter case.

(d) Today's the typical user has a lot more computer resources (processing-speed, memory, storage, network connection, etc) at his/her disposal than even a few years ago... this means that what would have been a major performance issue a few years ago, may no longer be so... 

For example, suppose that the modification above adds 1000 additional "steps" to the typical LaTeX run, and each step on average involves 20 raw CPU instructions (these numbers may or may not be realistic, they are only for illustration)... that would be 20 thousand CPU instructions for EVERY run... sounds like a huge problem, 20,000 additional instructions PER RUN... Yet, today a typical PC CPU can do 20 billion of instructions per second (20,000 MIPS), so the additional 20,000 instructions per run would induce a meagre micro-second of running time!... that is, even after one million runs, the user would have only "wasted" one second (in total)!
http://en.wikipedia.org/wiki/Instructions_per_second
Compare that to the time a typical "newbie" could waste trying to "solve" the "LaTeX cannot find a class in my home tree" non-problem..


> Also, please understand that we are currently concentrating on 
> preparing a release, so this is not exactly the best moment 
> to discuss such big changes (which, as Karl said, 
> require careful thought). But be assured that 
> we won't forget to discuss it for a future release.

Thank you. As I indicated elsewhere, I am only suggesting -- for the benefit of others, I hope --... I am well aware of the many advantages of the free-software development model, but also of its limitations... I hope and trust to the extend possible that the above issue will be addressed in the most appropriate fashion, as soon as possible/practical.

Best,

Virgil