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

Gerben Wierda Gerben.Wierda at rna.nl
Fri Aug 24 10:01:23 CEST 2007

On Aug 24, 2007, at 01:31 , Karl Berry wrote:

> Hi Gerben,
>     The basic idea (as I can gather) however is
> Right, basically.
>     Scheme-gust and scheme-tetex for instance depend
>     on both Collections and Packages directly.
> That's normal and unavoidable.
>     collection-langcyrillic has files.
> That I'm surprised about.  I'll change it.
>     there are chunks (these contain files)
> Sounds like TL packages.

No, my current stupid setup is not as rich. No dependencies for  
instance. It is just a set of file, nothing more.

>     and there are sets of chunks.
> Sounds like TL collections and schemes.  If you want to call them
> "subsets", go right ahead.

Again, no dependencies. Anyway, my current limited setup is not what  
this is about. I wanted to follow TL more.

> If it'll help you if we rigorously enforce that collections (or
> "subsets") don't have files themselves, that's ok by me.
>     this information is also already there in the file lists.
> But the way that information *gets* into the (autogenerated) file  
> lists
> is by having the category in the (hand-maintained) .tlpsrc file.

But they are there *and* the category is there.

OK. I am working from the TLPDB object as my starting point.

> I can agree it is not theoretically necessary.  The tlpdb generator
> could, in principle, search all texmf* trees for the package info.  I
> would like to have our packages be able to cross the texmf boundaries,
> it would be very helpful for things like perltex, but I am highly  
> unsure
> as to what will be affected.  It's never been done that way before,  
> and
> would need to be tested before we make such a sweeping change.

My feeling is that at the package level, it is not a big deal. In  
fact it is already the case. What about a collection or package in  
category Package that depends on something in TLCore? Expand it and  
you'll install stuff in texmf and texmf-dist.

Crossing boundaries is already the case. What you need to decide is  
name space uniqueness for TLPOBJ names.

>     I think we have in fact just one thing (as reflected in TLPOBJ),
> Since we have TLPOBJ now, I don't exactly see what you're proposing
> that's different.  A different way of thinking about it, I guess.

No. See my other reply. But also here: Given that a Scheme, a  
Collection, a Package, a TLCore and a Documentation thingy all are in  
fact a TLPOBJ they are already functionally the same. Hence the  
direct files in the langcyrillic collection. It is only a collection  
in the eye of the beholder, IT-design wise all  these things are now  

>     We could still tag the subsets with properties.
> So, if you like, think of the "category" field as a property of the
> TLPOBJ.  Since, as you point out, there are presently no rigorous  
> checks
> for the different "levels", they are in fact already all equal, it  
> seems
> to me.

Yes, that was my point. 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  
and it offers a start for non-unique pkg names in different  
directories (though this is not complete as the categories are not  
used in the perl interface to access items)
Anyway, I think having something that stands for "where things should  
go" is nice, because it offers people to use TL as input but organize  
it slightly different (e.g. I could say that Packages go to  
texmf.texlive-dist and have my own texmf.gwtex-dist additions next to  

>     I was also wondering if all subsets should have complete  
> dependencies.
>     ...
>     version checking for dependencies.
> I don't disagree in principle with either of these ideas, but I  
> know of
> no way to implement them.  Dependency information is simply not
> available.  Often the authors themselves don't even know which  
> versions
> are compatible with which other versions, and certainly no one else
> does.
>     I think it would be better if CJK would depend on collection- 
> latex.
> I don't mind adding that particular dependency.  I can see that  
> that one
> could make a difference in practice.
> As things stand, I have simply continued Sebastian's practice of  
> adding
> dependencies when told about important ones.

That is the right way. I think TL could be the repositpry of the  
dependencies and they are not very volatile so easy to maintain.

Remark: For TL itself these things are not very important. After all  
install sh can have specific knowledge which complements what is in  
the TLPKG info.

But as a source for other distributions (think MikTeX, gwTeX) it is  
not possible to rely on the information hidden in shell scripts of  
TL. So, something being a scheme should mean that it is something the  
use can select to install and get some sort of complete setup for a  
particular purpose (e.g. a scheme-context if you are not interested  
in LaTeX).

Anyway, I think the basic ideas in what has been produced are not all  
that evil. But they are not orthogonal.

I'll see if I can come up with some ideas.



More information about the tex-live mailing list