Anssi Hannula wrote:
> 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.
>  
Correct, but the author does. It is the author who is making the
decision about whether the dependency needs to be version specific or
not based on how the software was written.
> The release of libXXX.so.3 could completely change the interface and the
> application would no longer work.
>  
This applies to everything, and while true, this is why you have
software maintainers, change documentation, testing strategies and
release cycles.

regards,
Steve

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