[tex-live] Re: tex *live* packages [was: .. acronym package missing
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
> If failed to produce package files according to 1)
> 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.
More information about the tex-live