Marius and all, On Thu, 2006-06-01 at 13:02 -0500, Marius Schamschula wrote: > Yuri and all, > > I've been monitoring this thread for a while. > > Using package/ports management systems is a good idea, but... > > teTeX can be built by the standard ./configure, make, make install.
A very valid point, especially given your concerns further down, but the one drawback of "./configure, make, make install" is that it doesn't allow for a sufficiently sophisticated dependency checking (even though ./configure can do some of that) for package management. In other words: ".configure, make, make install" will easily suffice and even be the preferred choice when one offers just one set distribution as teTeX does, and does very well I might add. When, however, one wants to offer the user/administrator the option of easily installing or deinstalling additional packages with dependency checking, "./configure, make, make install" just will not do the trick: sooner or later things become a mess. Example: 1) User installs package P, which requires package A, but only a version no later than 1.2. ./configure checks for this and generates an error when this condition is not met. 2) User installs package Q, which requires package A, but only version 1.4 or newer. Configure checks, complains, user updates A, and tries again. Package Q works. 3) One month and 20 installs later, user tries using package P and discovers that it is broken. Why? How? No idea. Lots of work loom ahead. Any reasonable package/ports management system will avoid this. I stress that teTeX worked fine without packages/ports, but then again: it didn't need it because it has been thought out well, and suffices as-is for the majority of users. If TeXlive is to supersede teTeX most users _will_ require either a) several monolithic builds of various sizes (the "minimal, large, huge, all" or "teTeX subset, full TeXlive" options as have been mentioned") or b) packages/ports. Perhaps your criticisms point towards option a) being preferable over b)... > There are many computer platforms and almost as many package/porting > systems. These systems are often very much incompatible with each > other and using more than one on a machine can lead to major > problems. As a Mac user I read the mailing list for DarwinPorts, the > currently largest Mac OS X/Darwin ports system in terms of number of > available packages. There recently was a lengthy thread on variants > versus dependencies. To recap this in short: unless the packager > builds a "plain vanilla" version you end up with astronomical numbers > of variations on dependencies. Note: Both DarwinPorts and Fink list > teTeX 3.0 ports. There is no mention of TeXLive. Indeed you are right. Two solutions seem to exist. Either do as all other developers do when there are too many incompatible standards to choose from: create your own new standard that is incompatible withy as many of the existing standards as possible, or refrain from using package management at all. > For my needs a small package such as the present teTeX is more useful > that an expansive TeXLive. Many of pieces of software I install on my > own machines need TeX for building documentation (e.g. octave). > Asking the end user to download the equivalent of a DVD or at the > very least a CD, or for that matter have their computer build > something this large, makes no sense to me. True. And even true for the majority of users. But should perhaps TeXlive not cater for the niche audience of - say - a big server at a department were scores of people use TeX, many of them with completely different needs regarding the packages that have to be installed, and none or hardly any such package being specific to any one user? I.e. having users install their own packages means many users all installing package X, and thus wasting disk space and requiring a certain level of understanding of TeX installs, while at the same time hardly any package is being used by the entire department? I have worked at several such places, and work at one now. On the other hand, most places like that do have a rather knowledgeable SysAdmin who generally is able to install additional packages systemwide even if teTeX doesn't have them. > What I need is to be able to pull via ftp/http or from cvs/svn a > (sub-)tree that I can compile as above that provides the equivalent > functionality of teTeX. Many users will need the same thing. The problem is making the subtree thing work for all subtrees the maintainers care to maintain (or all subtrees users require?). Summarising: "one size fits all" is easiest to maintain, and has served us well for years; "one of these four sizes fits anyone" is slightly more complicated but works very well too, and also offers the "default size fits all", whenever required; "ports/package manager" requires a lot of thought, planning, work and continuous upkeep, but if done well offers far greater flexibility where any user can tailor the texmf tree exactly to their needs, or go the easy way and go with (one of the) default(s). I'd say: the more flexibility the better, but the whole endeavour needs to remain within reason, so let's not try and attain flexibility we can't create or maintain. Just another two pence. Or cents or whatever. Cheers, Yuri.
