[Bug 153463] [PATCH] Make Kompare build/work in KDE 4.0 SVN (3.96.2)

Andreas Pakulat apaku at gmx.de
Tue Dec 11 18:20:40 CET 2007


On 11.12.07 16:58:33, Kevin Kofler wrote:
> > I don't think adding a SOVERSION makes much sense as there's no BC
> > guarantee for those two libraries - they are simply convenience libs to
> > not have to build the sources of each lib three times when building
> > kompare. So if we add a SOVERSION we need to make sure to increase it
> > every time we break BC in the libs.
> 
> Well, technically an arbitrary constant SOVERSION and no version at all have 
> the exact same effect there (what's the technical difference between a foo.so 
> which doesn't maintain any BC and a foo.so.31337 which doesn't maintain any 
> BC? In both cases, packages will fail at runtime without the RPM soname 
> dependency mechanism detecting any problem), it's just the expectations which 
> are different.

Uhm, a shared library which doesn't increase its soversion on BiC
changes is not an Option - IMHO. 

> If you want to use libdiff2 in KDevelop, won't we need a properly versioned 
> and BC-maintaining library anyway?

Yes, but thats something for the future, KDevelop4 won't be released
before KDE 4.1.

> That said I don't think we're ready for that right now.

Correct and thats also exactly why I didn't add the soversion. We don't
know yet wether the library can be kept BC for some time in its current
state (besides that the classes are not designed for easy BC keeping
anyway). 

That said: I agree that its not nice to have to install kdesdk-dev(el)
to be able to use kompare. So the question is which evil we choose, or
rather you, its your project now after all.

Andreas

PS: If you think its important enough to have a soversion I vote for
0.9.0 to have at least some indication that these libs aren't considered 
rock-stable for some years to come.

Andreas

-- 
You will be singled out for promotion in your work.


More information about the Kompare-devel mailing list