In data mercoledì 25 novembre 2020 02:15:04 CET, Norbert Preining ha scritto: > I would like to ask your comments concerning the following MR: > https://salsa.debian.org/qt-kde-team/pkg-kde-tools/-/merge_requests/5 > > Next is the text of the MR, and below it some technical explanation and > usage for locked upgrade of Plasma.
Thanks for the MR, and the patience for this review. I have, however, concerns on the actual implementation using this "plasma-base", and how it does not help solving all the issues. > Depends: plasma-base (>= 5.20) > Breaks: plasma-base (>= 5.21) FYI: you can do the same with: Depends: plasma-base (>= 5.20), plasma-base (<< 5.21) Even simplier, using Provides: Depends: plasma-base-5-20 > Questions > ========== > > [...] > The idea is that we can keep plasma-base at the previous version, and > thus ensure that the new packages cannot be partially installed, and > only bump plasma-base when all packages are ready. This way a concerted > update will be done. While this is a concern, I'd like to mention that a similar situation also affects the Frameworks libraries (i.e. upstream says they need to be at the same version), and that in the past the "big hammer" of long list of breaks in library and -dev packages was attempted. This solution, however, created more issues than it actually solved, and I see the same big hammer solution here creating more hassles than actually solving this. Problems happened in the past, so IMHO unless we understand what exactly happened (and why), then adding "solutions" might not actually solve those issues. I think I spotted few issues happened during the last 5.19 update, so I'll mention what I saw and what I suggest as possible solution(s). 1) kscreenlocker ABI break (#974538) Apparently the kscreenlocker library had an API/ABI break without an SONAME bump, and this was not noticed. A good step was adding a symbols file for the library [1], but it had one issue: it was added based on the _new_ version of the library, so any ABI change was simply not spotted. Easy to solve: when adding a symbols file for a library that does not have one, first add the symbols file for the _existing_ version of the library in Debian, then update it to the new version. 2) weak dependencies in kdecoration [2] kdecoration has 2 libraries: libkdecoration2 and kdecorations2private, and libkdecoration2 links to the private one (using its interface). In kdecoration 5.17, the private library had SONAME 6, while in 5.19 it changed ABI and had SONAME 7 (rightfully reflected in the packaging). kwin links to both the libraries, and from what I can see, the sequence that happened was the following: a) kwin 5.17 links to libkdecoration2 and to private6 b) kdecoration 5.19 migrate to testing ahead on kwin 5.19, so libkdecoration2 was upgraded from 5.17 to 5.19, and because of the dependency private7 is installed without issues (different library name from private6, so coinstallable) c) now kwin 5.17 tries to use libkdecoration2 5.19, which in turns loads private7... but kwin also links to the private library directly, so it loads private6 d) the private library has no symbols versioning, so there is a symbols conflict and then boom In this case, I see two problems: a) the dependency between libkdecoration2 and its private is not strict b) bumps of the private library result in different coinstallable packages (a) is not what happened in the 5.17 -> 5.19 case, but might happen in case of no SONAME bump of the private library; this is easily fixable, and I just pushed it [3] (b) happens because of the coinstallability of the private packages with different SONAMEs; while for the majority of libraries this is not an issue, it is in case the old and the new can be indirectly used at the same time. IMHO a potential solution can be to change the private package shlibs to be versioned: dh_makeshlibs -Vlibkdecorations2private-5-19 (similar to what Sandro did for PIM, more about it later) this should make sure that, on upgrade: - the old kwin linked to the old private library, so it got the old version shlibs (eg libkdecorations2private-5-19) - the new libkdecoration2 requires the very same version of the private library (because of [3]), and that provides the new version shlibs (eg libkdecorations2private-5-20) - the result is that either the upgrade is not doable, or kwin-common gets uninstalled - the new kwin migrates, depends on libkdecorations2private-5-20, which is now installable, together with the new libkdecoration2, so everything is OK 3) different migration times for the various components Some components migrated to testing faster than others: these are sources with autopkgtests (mostly the only 'acc' left, after the mass purge of the wrong 'testsuite' ones), which migrate in 2 days (assuming successful builds, no RC bugs, etc). This is what lead to e.g. libkscreen and kdecoration to migrate earlier. This is mostly a unstable -> testing migration issue, and not something users dist-upgrading from oldstable to stable will face. [1] https://salsa.debian.org/qt-kde-team/kde/kscreenlocker/-/commit/2320b40c8d6f3ba316c83a31bdba79dc8db6d208 [2] https://lists.debian.org/debian-kde/2020/11/msg00010.html [3] https://salsa.debian.org/qt-kde-team/kde/kdecoration/-/commit/ef87674a5c7bf553fda633a3920991f87e8fbea3 My ideas (also based on past experience) ---------------------------------------- It is clear that the majority of these unstable -> testing issues happen because of shared libraries. IMHO making sure we play nice with them (and viceversa) it is important that we distinguish them in two kinds, because they will need different handling: 1) really public shared libraries: all the shared libraries that are marked as public, and are actually used as such outside of Plasma: - the libksysguard libraries, used by kdevelop - the libkworkspace library, used by kget - the libkwineffects library, used by kwin-effect-xrdesktop 2) Plasma-internal shared libraries: shared libraries that are "public", i.e. with installed .so symlinks and headers, but in reality are public only because they are used by other Plasma sources Regarding (1), the only real solution is strong tracking of SONAME and ABI of these libraries, i.e.: - follow upstream SONAME bumps when they happen - check the changes between versions, and do our own ABI bump (using ABIManager, see e.g. syndication and libktorrent) in case upstream broke the ABI without an SONAME bump; of course, ideally we should report upstream about these situations, but sometimes it's too late even for that; for example, the libkwineffects library had a Debian-only package rename in 5.19 - check for potential behaviour changes without an ABI change Yes, this needs a lot of care, and we need to do that exactly because they are public, so we don't want to unnecessarily break any non-Plasma user of them. IMHO the proposed plasma-base solution is a way too big hammer for this, and it will not help with 3rd parties that use these public libraries anyway. Regarding (2), IMHO a potential solution is to use what Sandro did for PIM, i.e. have versioned shlibs for the libraries, so when you compile against the new version you get the new version dependency too. The only drawback of this approach is that I see a lot of code copy/pasted in many sources, so having it factored out on a makefile snippet (like library-packages.mk does) would be nicer. OTOH, there are not too many Plasma sources with libraries in this category, so even without a code factoring it would not be that much of copy/paste. For the rest of the possible dependencies: according to my past experience and what I've seen recently, this is generally not a big issue. Usually there are enough churns/file movals between desktop/workspace to avoid old/new parallel installations; this, plus tightening the library dependencies as I suggested above, IMHO should fix the vast majority of the issues. Of course, if I missed any troublesome case, I'd be happy to hear about them. To be explicit: I'd prefer to not adopt the proposed https://salsa.debian.org/qt-kde-team/pkg-kde-tools/-/merge_requests/5 and the plasma-base usage for now. -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
-- https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-kde-talk
