Frank Griffin wrote:
> Steve Morris wrote:
>> 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.
>
> Steve, you miss the point, and it's probably the mainframe background
> talking.
>
> You are implicitly assuming a lockstep relationship between
> application providers and library providers which may exist in a
> single-vendor mainframe world, but doesn't exist here.
Actually I'm not. I am approaching this from the viewpoint of whether
software has been written for a particular version of a library or not,
irrespective of who provides the library.
>
> Apps which don't, can't, or won't upgrade from one major library
> version to the next are not uncommon in Linux. The apps are owned by
> their creators, and the fact that the library author decides to
> incompatibly upgrade the library imposes no requirement on them to
> conform. That's why Linux is designed to allow multiple versions of
> libraries to be be installed side-by-side, and provides for mechanisms
> so that the same system can satisfy the libXXX.so.1 requirement and
> the libXXX.so.2 requirement simultaneously.
I have no issue with this, but it is my understanding from reading past
threads, that the Mandriva Mirrors are snapshots containing only the
latest versions of packages because that is Mandrivas policy. Having
libXXX.so.1 and libXXX.so.2 coexisting is great, and libXXX.so should
always be pointing at the latest version, and software that is not
version specific should have a runtime dependency on the libXXX.so file.
> The flip side of this is that the apps can't just require libXXX.so if
> in fact they are dependent on a specific version, and the packaging
> rules expect them to err on the side of caution, i.e. be more specific
> rather than less specific.
I agree with you here and I am not arguing against this. If software is
dependent on a specific version then it should have a dependency on that
version, but it should not be a runtime dependency it should be a static
dependency.
IMO if the packaging rules require/expect you to provide dependencies on
specific versions of libraries even if you are not, then the rules are
wrong and need to be reviewed.
>
> In other words, the model wants packages to be as specific as they can
> be as to their dependency requirements. If the package can work with
> a later version, the packager is expected to update the RPM, which
> doesn't require updating the source code. But the existing system
> allows that to happen at a relaxed pace. The old version will be
> around as long as it's needed.
>
If software is not version specific a dependency on libXXX.so would make
that software independent of upgrades, and hence the rpm would not need
to be changed on library version updates.

regards,
Steve

>
>
>