[tex-live] Re: Debian-TeXlive Proposal II

Frank Küster frank at kuesterei.ch
Sat Jan 29 21:13:13 CET 2005


Gerben Wierda <Gerben.Wierda at rna.nl> wrote:

> On Jan 29, 2005, at 17:56, Frank Küster wrote:
>
>> I do not suggest that tex-live drop the separation of TEXMFDIST and
>> TEXMFMAIN generally. I only suggested that the _Debian_ packages of
>> tex-live and of teTeX do it the same way, and I would drop the
>> separation. After all, it's just a question of removing one entry from
>> TEXMF = ..., and of creating the package in a particular way.
>
> Certainly, but I maintain another redistribution scheme which is not
> debian packages. And it is not per-file based but per-archive
> based. 

No problem - just stick to the way tex-live does it when installing from
the CD, and let us do it otherwise in the Debian packages. Since local
additions should generally not be put into TEXMFMAIN nor TEXMFDIST, I
think we need not bother about that; but if you prefer, we can arrange
for a common directory name for the tree that contains the files that
are in TEXMFDIST in the tex-live CD.

> The situation is more complex even. What if something changes
> wrt location. Someone changes layout of some package. You only install
> the new stuff, but how do you make sure the old stuff is removed.

That's what a package management is for.

> Unpacking on top of something only solves half the problem. In the
> long run, it is possible to get doublures, e/g/ older and newer stuff
> side by side in your tree etc. Which is why my setup has a coarser
> granularity.

As I said, this is not a problem in a Debian package. Or, to put it the
other way round, the package managment system in Debian was developed
exactly because this problem occurs all the time, and cannot be solved
by separating directory trees in most cases.

> Unless
> debian packages have a memory (e.g. update them they still remember
> what files were installed before they were updated and those files are
> rmeoved before the new ones are installed, you run risks like this one.

They do have a memory, that's what it's for. When I explained that they
are like "installation routines" (like InstallShield), I must admit that
this was a bad analogy. I simply didn't remember how bad upgrades can
work on different systems...

Regards, Frank


-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



More information about the tex-live mailing list