On Friday, October 1, 2010, Lubos Lunak wrote: > (http://linuxtesting.org/upstream-tracker/versions/kde-libs.html), which is > not as green as it should be.
one of those is a commit by a plasma contributor that snuck one past us doing commit reviewing. it's really hard to catch every such event, and i agree with you that it's probably innevitable unless we have some automated testing. thank you for getting that going. it's quite awesome. > with e.g. kdeedu libs? I'm asking because, consider e.g. these errors from > an attempt to uninstall kdebase/workspace package here: > > libkscreensaver.so.5()(64bit) is needed by (installed) > kdeartwork4-screensaver-4.4.4-2.1.1.x86_64 i think the expectation there was that kdeartwork would be installed in lock- step with kdebase. probably a hold over from the kde3 expectation of things. in any case, nothing in this library has changed in forever, but it also isn't ready to become binary compatible, mostly due to lack of dptr usage in public classes. that would be easy enough to fix, bump the .so #, and then commit that library to having BC. > libkworkspace.so.4()(64bit) is needed by (installed) > ktorrent-3.3.4-4.1.x86_64 libkworkspace.so.4()(64bit) is needed by > (installed) kor-0.3-2.2s.x86_64 libsolidcontrol.so.4()(64bit) is needed by > (installed) > ktorrent-3.3.4-4.1.x86_64 ktorrent shouldn't be linking to any of these. > libsolidcontrol.so.4()(64bit) is needed by (installed) > kbluetooth-0.4.2-3.1.x86_64 > libsolidcontrol.so.4()(64bit) is needed by (installed) > NetworkManager-kde4-libs-0.9.svn1057339-4.1.x86_64 afaik libsolidcontrol is being phased out. networkmanager is also likely to be moving into kdebase/workspace/ at some point anyways, which will make this one "go away". kbluetooth is perhaps another good candidate for similar movement. > libtaskmanager.so.4()(64bit) is needed by (installed) > ktorrent-3.3.4-4.1.x86_64 oi vey. another library they should not be linking to. > Looking at how KDE provides various libraries leads to a number of WTH > questions, like: > - WTH is the ABI stability documented, besides kdelibs? nowhere, probably :/ > - WTH does e.g. libtaskmanager seem to have soname versioning following SC > version, like stable kdelibs libraries do, but it's not actually stable? because the intention was to eventually make it BC. it obviously didn't happen, things continue to evolve in it. we could certainly make a deadline for keeping BC (e.g. 4.6) and freeze it there. or we could keep going as we are currently (breaking BC from time to time, but not in a stable branch), and put NAMELINK_SKIP in there. would that be enough? > Therefore I propose the following: > - private libraries do not (obviously ...?) install their .h files and do > use NAMELINK_SKIP option in install (see e.g. > http://websvn.kde.org/trunk/KDE/kdebase/workspace/khotkeys/libkhotkeyspriva > te/CMakeLists.txt?r1=862343&r2=895764) > - ABI stability for each public > library is documented, I would suggest a README.<library> file in sources > and in the main doxygen page README files tend to bitrot IME. apidox is a good place. techbase is another good place. a "whitelist" page showing all libraries that have BC commitments (with the implication that if we ship them, but they aren't on that list, don't expect BC) would make sense to me. it's probably the easiest place to find these things for 3rd parties. > - ABI of each stable library (obviously) does not change > - whenever ABI of an unstable library changes, its soname is increased > (which means that each library will need in its CMakeLists.txt something > like this > http://websvn.kde.org/trunk/KDE/kdelibs/plasma/CMakeLists.txt?r1=879765&r2 > =879766& , handled manually, instead of generic macros) > - the release team howto gets a new entry 'each new version is ABI tested > before release' sounds great. and again, thanks for bringing this tool to KDE :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
