[tex-live] Matching TL package setups to my own
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
> 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
> as to what will be affected. It's never been done that way before,
> 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
> for the different "levels", they are in fact already all equal, it
> 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
> 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
> are compatible with which other versions, and certainly no one else
> I think it would be better if CJK would depend on collection-
> 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
> 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
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