[RFC] pkg-kde-tools: auto-injections of dependencies

Mon Dec 7 00:13:27 GMT 2020

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20201207/c5e23faa/attachment.sig>