[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Binary compatibility broken? between 3.3.1 and 3.3.2
From: Rex Dieter <rdieter () math ! unl ! edu>
Date: 2004-12-02 17:51:16
Message-ID: 41AF5614.4060005 () math ! unl ! edu
[Download RAW message or body]
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic