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

[Norbert Preining]

Hi all,

Unfortunately I am back to net-reality only for a short time, but a few
comments:

First of all, the new infrastructure is new, so changes can make sense,
but should be well proposed.

But with all the proposals and discussions we should keep in mind that
many of the things in the new infra were created like they are because
we want to be able to keep the current installers in case we don't get a
new one. We cannot be sure that we have a new installer, and now we can
just create the list files and be sure (hope!!!) that the installer will
work.

On Don, 23 Aug 2007, Gerben Wierda wrote:
> But this is not enforced. 

> I would like to propose a change for TL structuring such that relation and
> use are enforced and thus installers need no special knowledge but can
> rely on structural information in the TLPDB.

Since schemes and collections are maintained by hand, all this stuff can
easily done in the tlpsrc files. Enforcing can be implemented easily in
the perl modules, if we want it.

> First, my suggestion would be to drop theb difference between schemes and
> collections. Just have collections. collection-tetex is just another
> subset of TL (but see below for schemes).

My heart does not hang on schemes at all, I never took a look at them.

BUT KEEP THE FOLLOWING IN MIND:
- Every package/file is in EXACTELY ONE (!!!) collection
- but can be contained in many schemes.

So collections are disjoint subsets of all texlive files, whose union
should be ALL files in texlive, 

while schemes make up not necessarily disjoint subsets.


So there IS a difference

> I would also drop the difference between TLCore, Package and
> Documentation. After all, while it is true that TLCore should go to texmf,
> Package to texmf-dist and Documentation to texmf-doc this information is
> also already there in the file lists. Hence, I could currently easily put
> a texmf-dist/foo/bar file in a TLCore package and it would just work.
> Having these three categories *and* the subdir info in the setup is
> redundant. Having them also not enforced by structure is a possible source
> of confusion.

In fact I proposed that we drop the texmf/texmf-dist/texmf-doc etc part
to make it relocatable, but this is also a bad idea due to other
reasons.

> We could still tag the subsets with properties. Scheme could be such a

But this doesn't make it simpler. Or do you have a format and an
implementation at hand?

> I was also wondering if all subsets should have complete dependencies.

Impossible, as Karl answered. We try to cope with most important deps,
but this has never been completely right, and probably will never be.

> Furthermore, I think it would be good to have some sort of version
> checking for dependencies. The new beamer may depend on a newer version of

Karl answered this, impossible.

On Don, 23 Aug 2007, Karl Berry wrote:
>     collection-langcyrillic has files. 
> 
> That I'm surprised about.  I'll change it.

Thanks Karl.

> If it'll help you if we rigorously enforce that collections (or
> "subsets") don't have files themselves, that's ok by me.

And with me too, in fact I didn't know that there are files directly
listed in collections ...

> 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,

They CAN, trivially. Just add respective patterns or files into the
tlpsrc... nothing is enforcing us now to keep the 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.

I would prefer to have the bin-stuff remaining ... 

On Fre, 24 Aug 2007, Reinhard Kotucha wrote:
> Karl, sorry, but I totally agree with Gerben and I doubt that it's
> unavoidable.  It is very difficult to write an installer if a scheme
> or collection can contain arbitrary stuff.

As said, I really much agree if we can boil down that collections do NOT
contain direct files, but only depend on other collections and include
packages. What schemes are doing I don't care ;-) but I guess that they
either should depend only on collections ...

> It would be nice if a scheme is just a set of collections.  Everything

Yes.

> The fact that schemes contain packages is very nasty indeed.

Yes.

> agree with him.  What we have at the moment is horrible.

Well, it is not that bad. I guess we can clean up the (few?) wrong cases
quite fast.

A quick check showed that:
- under all the collections there is only collection-langcyrillic
  containing runpatterns

- on the schemes side there are only scheme-gust, scheme-tetex, and
  scheme-xml depending on non-collections.

AND: I see that it makes sense to have package dependencies in the
schemese, especially when we talk about documentation stuff, which is
separated into language collections, so picking out single packages for
some schemes would make sense.

> Karl, if things will remain as messy as they are, I doubt that anybody
> is able to provide a reasonable installer before TL-2008 will be released.

There are not that messy, if the installer would collect simple
Package(s) it would work, taking aside the wrong occurrences of
patterns/files in collections-langcyrillic.

As said I see a use of including single packages in schemes, and that
cannot be too bad to be implemented.

On Fre, 24 Aug 2007, Gerben Wierda wrote:
> Here is another one: depends in a TLPOBJ are of the form "Package/ 
> foo" or "TLCore/bar". To use that name to get the actual TLPOBJ I  
> need to strip the first part.
> 
>                 $tlpkgname =~ s/^(Package|TLCore|Documentation| 
> Scheme|Collection)\///;
> 		my $tlpkg = $tlpdb->get_package( $tlpkgname);
> 
> I am throwing stuff away but without any ill effect. I do not need it.

Yes, true, but we still need this information for now since for the
generation of list files in case we have to use the old installer.

True that we can even generated this information because up to now
package names are unique across ALL trees, so if someone calls for
"foobar" we just check the category of this item. In fact the infra is
laid out so that packages across the whole tree HAVE to be unique!

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining at logic.at>        Vienna University of Technology
Debian Developer <preining at debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
			--- Douglas Adams, The Meaning of Liff