Steve Morris wrote:
> Frank Griffin wrote:
>> 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.

We only provide older versions when they are still needed by something.

> 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.

But the software cannot know whether the dependency is version-specific.
The release of libXXX.so.3 could completely change the interface and the
application would no longer work.

>> 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.

As said previously, we should not use static linking because of
1) the very large size.
2) if there is a security update in e.g. glibc, we would have to rebuild
*all* packages so that the fix goes to all of them. We don't want do
that, and users especially would not want to have to upgrade all their
packages.

> 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.

As said previously, one cannot guarantee that the application works with
the next version of the library.

>> 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.

Again, one cannot guarantee that the application works with the next
version of libXXX.so.X.

--
Anssi Hannula