[tex-live] Re: tex *live* packages [was: .. acronym package missing doc]

Sebastian Rahtz sebastian.rahtz at oucs.ox.ac.uk
Wed Feb 11 23:42:00 CET 2004


Itay Furman wrote:

>
>
>The information to produce all package files is embedded in those 
>files, sometimes in explicit statements from the contributors as 
>in the above example; sometimes implicitly.
>
>One may try the following approach:
>1) Extract instructions for producing package files (beyond 
>   the 'latex file.ins') from
>	readme, README, FILE.ins, FILE.dtx, ...
>2) If	none is found
>   	or
>   If	failed to produce package files according to 1)
>   then
>   	use current approach
>  
>
this seems to imply _reading_ the files. That is not on.
a) I don't have time; b) (most importantly) I don't want to
have to reread them when the package changes (do you realize
how many package updates there are a week? a lot...)

>As I see it, the advantage here is that, the extraction engine, 
>1) can be built and improved _incrementally_ as more ways in 
>which contributors embed instructions are 'discovered' and 
>successfully handled by the engine.
>  
>
this is basically what I do. that is to say, my sausage machine
has defaults, and overrides. As I meet a new funny package,
I add overrides for it. generally, it works.

>In addition, record the way each package was handled in some sort 
>of DB to use in following years to speed-up/double-check the 
>migration procedure. (Is this what tpm2 for?)
>
>  
>
yes, precisely. my current sausage maker is a messy giant perl script.

>
>The same approach as above might work here, too?
>Ambiguous cases handled by symlinking to doc/.../?
>  
>
ah, symlinks. cf the other discussion about CVS. you can't have symlinks
under CVS :-}

not to mention the fact that they don't work under Windows properly.

sebastian


More information about the tex-live mailing list