[tex-live] Matching TL package setups to my own

[Gerben Wierda]

On Aug 25, 2007, at 01:59 , Karl Berry wrote:

>     Another circular dependency: bin-wordcount and wordcount
>
> Strange though it is, I'm not sure circular dependencies are an error.
> I don't see any other way to express it.

package foo:
	depend foo-bin
	depend foo-run

Of course if foo-bin below again has dependencies you still can have  
circular dependencies.

It is therefore I think better to have items (which may not have  
dependencies but also cannot be installed/selected separately) and  
sets (which may depend on other sets and items)

set foo:
	depend item foo-bin
	depend item foo-run
set bar:
	depend set foo
	depend item bar-run
and then not allow circular dependencies in of sets. Anyway, that way  
you cannot get foo-bin without foo-run and v.v. but you also do not  
have nasty circular dependencies.

Anyway, I think one should better have leafs (stuff below which you  
do not *allow* dependencies) and which are the only ones who may  
contain files.

In simple cases this would mean you will have sets of one item. E.g.

set trivfloat
	depend item trivfloat-files

Stuff like execute should then only exist at set level (you only *do*  
things if you have everything needed.

> The better fix would be to have one package "wordcount" that includes
> the bin-wordcount stuff, but like I said, that is something that
> requires experimentation and work.

[snip]

> All names are supposed to be unique now!  Independent of category.
>
>     Categories are now used for two things I think:
>     - where should stuff go (texmf, texmf-doc, etc)
>     - how is it to be presented to the user (packages or schemes or
>     collections)
>
> That is true, and I agree they are not orthogonal ideas.  I don't  
> think
> the current situation does any great harm once the above is  
> understood,
> though.

Maybe I should explain what I am trying to do and what this (imo)  
means for this stuff in TL

My current redistribution packs up a part of TL's Master tree  
in .tar.bz2 files to be downloaded by i-Installer (chunks). These  
chunks can be rather large. E.g. a subset of TL's texmf-dist  
corresponing to the former teTeX texmf tree + what I used to add to  
that from TL. To make it possible for the user to minimize the  
download/footprint I do not pack the texmf*/source stuff and I split  
the texmf-dist tree in a chunk containing the  selections from texmf- 
dist/doc, texmf-dist/tex, texmf-dist/ftonts and the rest of my  
selection from texmf-dist. I do this so that if only a package in tex/ 
latex changes, the whole fonts business does not need to be  
downloaded again when the i-Package is updated. I also separate doc  
for the rest as you do not need doc to run TeX.

This is rather coarse and I have been wanting to make this far more  
finegrained. For that I only have one source I could possibly use:  
TLP. That means that my chunks should become based on the tlp's in  
TL, so I need to write a (perl) program to take TLP as input and  
produce the basics of an i-Package.

I still want the user to be able to select something high-level, like  
scheme-tetex.
I want the use to be able to select collections and packages
I want the user to be able to choose to not install doc or source  
until needed (which is almost never)
And most certainly I want the build process from TLP to i-Package to  
be automatic. If too much hand fiddling is required there is no way I  
can keep that up.

So, in the end the TLP structure must have enough information to  
create the behaviour of the installer. The whole setup then becomes  
data-driven, which is the important point. install.sh can do  
installation on that basis, but so can the i-Package (and others) and  
it is both based on the same information in TLP.

Circular dependencies are problematic for that kind of automation  
because they make parsing the stuff too complex. It is also not  
needed. Multiple texmf trees is OK (I am in favour of splitting the  
stuff that is generated by make world in Build (which should go into  
texmf) from the stuff that is maintained otherwise (which goes into  
texmf-dist and texmf-doc).

(I had to stop writing this message and could only come back to it  
after a day or two, so the whole thing is not very coherent).

G