[OS X TeX] Finally we are grown up
Gerben.Wierda at rna.nl
Sat Nov 18 18:11:38 EST 2006
On Nov 18, 2006, at 15:21 , Martin Costabel wrote:
> Gerben Wierda wrote:
>> On Nov 18, 2006, at 03:21, Enrico Franconi wrote:
>>> The lack of dependencies' maintenance in the i-installer is what
>>> made me choose fink (with its GUI, FinkCommander), and now
>>> darwinports (with its GUI, PortAuthority) to install libraries
>>> and binaries other than the TeX distribution. If you have a
>>> complex unix system, you can not simply upgrade/uninstall a
>>> library without checking whether this has been used by other
>>> stuff, which may depend on it or on a particular version of it.
> I think Enrico raises a very valid point here. The i-installer
> adheres, like many contributors to this list, basically to a
> "single application" philosophy. For a student writing his PhD
> thesis or someone occupied for years by his Opus Magnum, this is
> legitimate; they will use their computer, besides doing their E-
> Mail and browsing the web, essentially for one other application,
> in this case TeX. But for many others, the "single application"
> approach belongs to the list of "single tasking" and "single user"
> that were once valid for Mac users and still are to a certain
> extent, but should not be accepted any more as a principle.
>> There are several strategies possible here. Fink & Darwinports
>> follow the "splendid isolation" strategy. This enables them to
>> have more control. i-Installer installs what is the result of
>> downloaidng and compiling from source and installing in its
>> default place (generally).
> It is all very nice mingling with the crowd if the crowd consists
> essentially of yourself and your family. As soon as strangers get
> in, things quickly become much less cosy. Enrico mentioned the
> problem of dependency on a particular version of a library, and
> this is impossible to solve if several third-party applications
> install their libraries in the same default places /usr/local/lib
> and /Library. These default places rather quickly become ugly
> garbage dumps where after a while you don't even know where the
> things came from that you find there.
>> i-Installer has dependencies handling (both required and
>> recommended) and you will get warnings about the inavailability of
>> required dynamic libraries. The funny thing is that it does not
>> matter to the user if these libraries have been installed by i-
>> Installer or any other system (like downloading and compiling by
>> hand). i-Installer will perfectly detect the availability of
>> freetype as a prerequisite for ImageMagick but it does not force
>> you to use i-Installer in installing this.
> This is all very nice in an ideal world where there is only one
> version of libfreetype, or where different versions of libfreetype
> are compatible with each other. In the real world this is not the
> case. As an example, here are two reasons why your dependency
> control may be insufficient as soon as there is some other
> application that installs freetype in the same default places as
> the i-installer:
> - If your ImageMagick is linked against a certain version of
> libfreetype, then replacing that version of libfreetype by one with
> a lower compatibility version (although the main library version
> may be the same) will make the ImageMagick binaries crash.
> Replacing it with a later version may or may not work, depending on
> backward compatibility of the new library (and backward
> compatibility was not one of the strong points of freetype2 in the
> past). Likewise, installing libfreetype with i-installer may make
> other applications crash that are expecting a different version in
> the default places.
> - The current release 2.2.1 of freetype2 is broken on OSX/Intel
> when the old-mac-fonts feature is activated. A patch is known, and
> you may be incorporating it into your release or not, I don't know.
> But if some other application or a standalone install of freetype2
> installs the "official" libfreetype-2.2.1, you will get crashes
> that you cannot control.
>>> If you use your computer in several different ways, the i-
>>> installer may disrupt in a very subtle way your system.
>>> It seems to me that the i-installer is very good at its job for
>>> users who do not install any other library in any other way.
>> The philosophy of i-Installer is the opposite, see dependency
>> example above.
> To overcome the "single application" restriction, there exist only
> two possibilities on the Mac:
> Either one uses app-bundles for everything, where all required
> libraries are always stored inside the bundle. Every application
> that needs libfreetype will then install its own copy in its own
> private place. This is the NextStep/OSX standard way, ideally
> suited for commercial software or shareware. It is also a huge
> waste of resources.
> Or one uses a package manager like Fink or MacPorts (FKA
> DarwinPorts) to control everything outside of the system. This is
> similar to what every Linux distribution is doing. It is also where
> i-installer seemed to be heading recently ("everything" then
> meaning "everything a typical latex user might be interested in"),
> but it is much too big a task for a single person to manage, it
> needs a community of developers.
Basically, I need to spend time on other issues than discussing the
philosophy of i-Installer, so my apologies for not getting into this
discussion any further (other than to say that afaik the finks do
have downward dependency handling, but not upward and suffer from the
same troubles wth mixing and matching apps from various sources as
almost all setups).
A solution for this mess I know of is "NIX" which even is per-user
but handles *all* dependencies and even allows you to mix and match
all kinds of tools with all kinds of dependencies where you have
something I would call multiple downward dependency trees
------------------------- Info --------------------------
Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
& FAQ: http://latex.yauh.de/faq/
TeX FAQ: http://www.tex.ac.uk/faq
List Archive: http://tug.org/pipermail/macostex-archives/
More information about the MacOSX-TeX