Re: Progress on Mac installation cloning

[Mojca M. <moj...@gm...>]

On 4 March 2016 at 00:29, Ethan A Merritt wrote:
> On Friday, 04 March, 2016 00:02:06 Mojca Miklavec wrote:
>
>> > Are you saying that I should make an /opt/gnuplot directory
>> > on the build machine, put the required dynamic libraries there,
>> > and tell the gnuplot build that the libraries are in /opt/gnuplot?
>>
>> Yes, that would be much better than installing dynamic libraries into
>> /usr/local
>
> I very much disagree with this.
> The whole point of shared libraries is that they are, well, _shared_.
> When a single copy of the library is shared, that means security fixes,
> library bug-fixes, and upgrades benefit all programs on the system.

Except that Thomas most likely won't be providing security fixes to
his students, will he?
And if he now installs libpng 1.6 and after a while "someone or
something else" installs libpng 1.7 (or 1.5), gnuplot will suddenly
become broken as it will no longer work with the other version of
library without recompiling it.

The paradigm works well on Linux, but please understand that this is
not the case on OS X (or at least go complain to Apple).

If someone wants security fixes for dependencies of gnuplot, a package
manage should be installed (which is something that Thomans explicitly
wants to avoid).

> If you keep a separate copy for each program then you would have to update
> and rebuild each of those separate copies in parallel. What a headache.

How often do you rebuild applications on Windows?

>> > And your point is that the dynamic libraries in /opt/gnuplot
>> > are less likely to get clobbered than if they are in their
>> > "standard" places?
>>
>> Yes.
>
> Where "clobbered" can mean "updated or fixed"

If Thomas puts a random library with an arbitrary name to /usr/local:
what or who exactly is going to fix it? Again, if someone will replace
one library with an ABI-incompatible version, gnuplot will stop
working anyway (and we know that these students have no clue how to
rebuild gnuplot, so they'll just stop using it).

Worse. If I would try to compile gnuplot from CVS a few years from now
and I would have the latest library installed (in /opt/local, provided
by the package manager) plus that old and outdated libpng in
/usr/local (from the USB stick by Thomas), the compiler will pick up
that outdated vulnerable library and will end up with gnuplot linked
against a vulnerable version.

> That is the exact opposite of a supportable system layout IMHO.
> If there is a bug in the library, that is exactly when you _do_ want a
> single shared copy so that fixing the bug benefits all users of the library.

Again: how exactly do you address that problem with gnuplot binaries
on Windows? Where do you get the shared libraries from and who makes
sure that they are always up to date?

It's one thing when a huge herd of developers and security specialists
make sure that you'll get the latest fixes when you run "sudo apt-get
upgrade" and it's a completely different thing when a Windows (or OS
X) user gets a bunch of binaries from a friend. Who and how exactly
will take care of patching those binary files?

> Now it is true that if you manage to build a defective copy of a library
> then putting it in /usr/local/lib could harm other programs as well as
> breaking your intended client. But putting that defective library in your
> private directory isn't going to get you a working client either,
> nor would including it permanently in your executable as a static library.

The thing is that he could get a working gnuplot now. And then one
month from now something or someone could install a defect library to
/usr/local and gnuplot would stop working if it linked against the
library in /usr/local. If it would have a statically linked library or
if it was at some exotic location, it wouldn't be affected by that
broken library.

Mojca