Colin Guthrie wrote:
> 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
>
The point I was trying to make is that, using libGL.so.1 as an example,
modules that have a dependency on libGL should have that dependency on
the symlink libGL.so which gets modified by standard processes to point
to the latest version of libGL.so.*. If a module absolutely has to have
a dependency on libGL.so.1 because the module will not work with any
other version, then libGL.so.1 should be statically linked with the
module, as there is no guarantee that libGL.so.1 will be around forever.
Modules that really do have that sort of dependency should not get
broken just because someone else decided to upgrade the dependent
package. The libplasma example is the situation that currently exists
that illustrates this.
A large number of packages could be impacted for a vulnerability fix,
but handling that is what your package management environment is for
(assuming packages are defined properly), and in a cooker environment
changes to a large number of packages is no big deal.
Statically linking modules does increase the disk space which as you
have said is not ideal, but then neither is writing software to be
dependent on a specific version of in this case libGL, which is what a
specific dependency on libGL.so.1 is implying.

regards,
Steve


>
>