Re: More fine-grained control in texlive?
Hi, Norbert.
Sorry for the late reply. I just discovered that I was unsubscribed from
the list. I'm subscribed again.
On Jun 28 2007, Norbert Preining wrote:
> On Don, 28 Jun 2007, Rogério Brito wrote:
> > Could we have a little bit more fine-grained control in the texlive
> > packages?
>
> Well, yes and no.
Hah, I hope that we can emphasize the yes part. :-)
> > Can I suggest you some partitions? For instance, we have
> > texlive-math-extra, but we don't have texlive-math-recommended, which I
> > would like to see for consistency purposes (and it would be useful too).
> >
> > Can we migrate fonts from -extra to -recommended? And can we fix some
> > descriptions of packages? I see that some don't have description, were
> > it would be quite useful for the packages to have.
>
> Simply said, no. We are following upstream's collections. So what
> collection there are we will transfer into .debs.
Well, as I mentioned to Frank, I didn't know about the organization of
upstream. But one thing is quite conspicuous: the size of some of the
pages is quite big:
rbrito@dumont:~$ dpigs
135200 texlive-fonts-extra
126180 texlive-latex-extra
56732 emacs-snapshot-common
45628 texlive-latex-base
37072 texlive-latex-recommended
30388 libgcj7-0
26940 iceweasel
25552 texlive-fonts-recommended
19784 texlive-base-bin
18056 pidgin-data
rbrito@dumont:~$
As you can see, the biggest packages that I have on my system include
packages from texlive. In fact, one thing that has just occured me is
that there is a *lot* of documentation on these packages.
Perhaps we could split the documentation on texlive-latex-extra-doc (and
similarly for other packages), for instance? I never cared for the
documentation in the tetex days, for the sake of using smaller
diskspace.
> (putting upstream hat on since I am also upstream) of course if you come
> up with a sensible splitting, which does not create too much problems
> and ensures more or less proper dependencies, I can implement it also
> upstream in TeX Live 2008.
I already suggested some things for Frank. Since I'm not really sure
that my messages are getting through (my ISP is failing me), I will
paste them here:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 - in tl-science, we have:
alg, algorith2e, algorithmicx, algorithms, pseudocode, clrscode,
complexity, computational-complexity, galois
These are strictly mathematic/computer science packages. Perhaps we
could have them in a tl-math-recommended?
2 - is tl-doc-base really mandatory?
3 - can we move some fonts out of tl-math-extra?
4 - in the current debian distribution, we have the package rcs-latex
and tl-latex-recommmended mentions that it has rcs. Is this a
duplication?
5 - the package euler (for math) is in tl-latex-recommended, while
eulervm (which I heard is the preferred choice) is in
tl-latex-extra. Is this correct?
6 - just for consistency's sake, we have beton (for text) in
tl-fonts-extra. I would like to see it in tl-latex-recommended, if
possible (so that we can typeset a text using the fonts from
"Concrete Mathematics").
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please, keep in mind that these are just examples of simple things that
I noticed when I decided to migrate to texlive today, to see if my
metapost problem would go away.
> But for 2007: No.
Ok, I can live with this (but the splitting of -doc would be a good
thing for users, I think).
I also want to make a stripped down live CD for some (Mathematician)
friends and this would help quite a lot.
> Ah and yes, if you want to move fonts from -extra to -recommended, which
> are they? It is again an upstream thing. But if upstream does it for
> TL2008, we can follow already in the Debian packages, but we need some
> argumentation why it should be made.
I think that I will check more and see which suggestions I can make.
Thank you very much, Rogério.
--
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat: http://freshmeat.net/projects/algorithms/
Reply to: