[OS X TeX] iInstaller and manually installed components
Gerben.Wierda at rna.nl
Tue Nov 30 16:06:46 EST 2004
> 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).
>> 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
[leaving out a reply to the first example as the reply is too
> 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.
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:
--------------------- 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>
More information about the MacOSX-TeX