[OS X TeX] iInstaller and manually installed components

[Gerben Wierda]

> On 30 Nov 2004, at 00:59, Martin Costabel wrote:
>> But here is a warning in the opposite direction: If you want to
>> compile your own Unix software, whether with Fink or darwinports or
>> "by hand", then do *not* install i-installer packages like libjpeg,
>> libpng, libwmf, imagemagick and so on. The reason is that these
>> packages install headers into /usr/local/include, libraries into
>> /usr/local/lib, and some config scripts into /usr/local/bin. Every
>> configure script and every preprocessor, compiler and linker will pick
>> these up, if you want it or not, because these directories are in
>> their standard search paths.

I generally install software in the default location provided by its 
source distribution. Normally that is /usr/local

>> Some compilations will already break early on because of this,

I would be interested to know which ones. Because they would also break 
on a source-compile install of the stuff I redistribute (because what I 
do *is* a standard source based install on my system which then gets 
packaged for other systems).

>>  others
>> will compile successfully, but the executables will be linked to these
>> libraries, and when you later on update or remove the i-packages in
>> question, your executables will crash.

Problems. Update: seldomly. Remove: of course. Which is true for every 
executable if you remove a shared library it depends on.

>> You also cannot run your
>> executables on another machine, unless it has exactly the same
>> collection of i-packages with the same versions installed.

Anyway, the entire warning is rightly made. However, my personal 
packages tend not to use dynamically linked executables (with some 
exceptions), just for that reason.

> I believe that people did not understand the importance of the argument
> of Martin. The point is about *management* of libraries, i.e., update
> or removal, for which the i-installer philosophy is completely
> inadequate; of course, the i-installer works quite well as far as just
> installation is concerned. The handling of dependencies in the
> i-installer, from what I understand, is very poor.

Handling of dependencies in i-Installer is very poor *by design*.

> I may update/remove
> a library which is essential for some executable without being warned.

The only way such a warning system can be implemented is if you install 
*everything* with one tool (which is the fink approach). That is a 
valid design (I have *nothing* against that Fink choice in itself. But 
there is the small fact that this design choice demands that its 
installs override any Apple Mac OS X versions silently and I consider 
that a bit of a security risk (not big, but I do not like it)).

Given that i-Installer's design philosophy is that it will not override 
parts of Mac OS X silently, it cannot work on the basis of such a 
system-within-a-system concept like Fink does. It therefore cannot 
offer a full interdependency service, and any attempt to full 
dependency intelligence would surmount to impossible AI-like qualities.

(There are some time consuming methods like scanning the entire disk 
(after library removal) for executables linked against libraries just 
removed). Something like this might be implemented (optionally) in a 
later version).

[leaving out a reply to the first example as the reply is too 
complicated]

> you install the library, you compile an executable that
> depends on it (system-wide), you update/remove the library with the
> i-installer and the executable crashes.

Or even, you install an i-Package with an executable that depends on a 
library from another i-Package and you uninstall the second one.

Of course, when you remove something from your system, you are 
*supposed* to know what you are doing. Sometimes people try to get rid 
of all that stuff in /System/* and their system stops working too ;-)

In terms of support questions, the above scenarios have so far not 
happened to me. But I agree that the set provided by i-Installer is 
small and not used generally by unix-affecionados.

G

PS. Generally, I like to be informed of any problems with respect to my 
packages so I can update. I do not update them myself (I have other 
things occupying me) and my model is that I react to signals from the 
outside. If nobody signals me, a package is not updated. This is energy 
conservation, as I would otherwise be updating stuff that is used by 
nobody. So, a package may be out of date. The right thing to do is: 
inform me.

--------------------- 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 Post: <mailto:MacOSX-TeX at email.esm.psu.edu>