Binary compatibility broken? between 3.3.1 and 3.3.2

[Rex Dieter]

> Am Thursday 02 December 2004 12:34 schrieb Leo Savernik:
> 
>>> Am Donnerstag, 2. Dezember 2004 10:02 schrieb Stephan Kulow:
>>
>>>>> > > Yet we can argue whether it is allowed to introduce new public symbols in
>>>>> > > patchlevel releases.
>>>
>>>> >
>>>> > We could, yes. But it would end up with: packages are supposed to require
>>>> > the patchlevel version they built against as minimum.
>>
>>> 
>>> Isn't it already this way?
> 
> Obviously not for the akregator RPM

Couldn't new public symbols be tagged in the shared lib, similar to how 
glibc does it, like:
libc.so.6(GLIBC_2.1)

So, this new kdelibs-3.3.2 symbol would generate a dependancy something 
like:
libkdecore.so.4(KDE_3.3.2)

If it was done this way, binary compatibility would be seemless, and it 
would make packagers' (rpm, deb whatever) life a lot simpler.

IMO, qt could try do to this to, even between qt-x.y -> qt-x.(y+1) 
upgrades, since the shared lib is the same libqt-mt.so.3

-- Rex