Steve Morris wrote:
>   This was a discussion about a runtime dependency on libGL.so.1 as
> opposed to a dependency on libGL.so and letting this link resolve to the
> current version. Anssi was saying that from a Mandriva viewpoint, given
> that if a module has a dependency on libGL.so.1 it is not compatible
> with libGL.so.2, that it is better to have a runtime dependency on
> libGL.so.1 rather than statically link it into the module. It was this
> train of thought that I was saying made no sense to me. It makes more
> sense to me to statically link this version into the module so that if
> the package that provides libGL.so.1 gets upgraded to the package that
> provides libGL.so.2, the module that requires libGL.so.1 would be
> completely unimpacted.

Erm, eh?

OK, forgetting the alternatives for now and considering only the mesa
libGL.so.1.....

This file is part of:
libmesagl1-7.0.3-2mdv2009.0

The 1 at the end of the package name is the library major.

If Mesa decided to ship a new major version the package that provided
the fictional libGL.so.2 would be called
libmesagl2-n.n.n-rmdv200x.y

This package would not conflict with the old one and the two can be
installed at the same time allowing older applications to work fine with
newer ones. This is ingrained in our packaging policy for precisely this
reason.

This is also why after a distro upgrade you have to remove quite a lot
of "orphaned majors". I have a little script that I use that compares
the urpmi database to the installed list of rpms and tells me any
installed rpms that do not exist in the repos. I can therefore easily
detect orphaned packages.

With regards to static linking you run into lots of problems.
1) If a vulnerability is found in a statically linked library, security
updates will require a huge amount of package updates. Runtime linking
is much better as only the actual package where the bug is is typically
required to be rebuilt (except in the case where the fix for the vuln
causes ABI breakage).
2) Applications become much larger and use more diskspace.

So given the above, can you tell me what the argument *for* static
linking is? (I think with the clarification of our packaging policy
above, your only argument is gone!).


> This to me is much more desirable than the
> situation we are currently in where specific kde4 packages can't be
> installed because 'no package provides libplasma.so.1'. The reason for
> this failure is that libplasma1 (if that is what the package was called)
> has been replaced by libplasma2 which provides libplasma.so.2. If the
> kde4 packages were statically linked with libplasma.so.1, this upgrade
> would have had no impact on them. This was the point I was trying to make.

This is a poor example. Here we have a whole set of packages moving
forward and you're picking a random point half way through the process
and saying "it's broken". It's not broken, it's in transition. This is
cooker, it's *not* a stable distro, and you cannot expect this scenario
to never occur. Static linking is certainly not a fix.... the fix is a
little patience or some of your own packaging work to move things along
quicker.

Col



--

+--------------------------+
|    Colin Guthrie     |
+--------------------------+
| cguthrie(at)mandriva.org |
| http://colin.guthr.ie/ |
+--------------------------+