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

[Norbert Preining]

Hi Pino, Scarlett, Patrick,

thanks for the detailed review and evaluation, that is much appreciated.

>   Depends: plasma-base-5-20

Ok, that would be definitely the better way, and there would be no need
for dh_injectdependencies since ${misc:Depends} is already there.

> 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.

I have used the "big hammer" for the TeX Live packages, but there are
hardly any shared libraries, so obviously my experience is not
sufficient to properly evaluate the possible problems.

Could you tell me what are the issues that would we create with the big
hammer?

Furthermore, I think this is independent from the very valid issue about
shared libs and symbol tracking.

But let us see what needs to be done **now** if we don't use the hammer ;-)

Do you think that an upload of the current state of experimental, with
recent changes you have done to master merged, does make sense? The idea
would be to make upload to experimental, see how upgrade tests work, and
make adjustments necessary, hoping that nothing slips through.

What do you two, Scarlett and Patrick say? Any opinion on the whole
issue?

> 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.

But this doesn't apply for the 5.20 case, right, since we have already
5.19 and would see changes?

> 2) weak dependencies in kdecoration [2]
[...]
> 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]

Thanks, that should take care of it after I merge it into experimental.

> (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:

Ok, but since we are targeting 5.20 for bullseye, we would need to
- Provide: libkdecorations2private-5-20
- add the dh_makeshlibs -Vlibkdecorations2private-5-20
Am I missing something?

Or is this all automatically done by your change in [3]?

> 3) different migration times for the various components

Yes, that is something that we cannot really influence (due to possible
bug reports), so the library dependencies (or the big hammer) needs to
take care of that.

> This is mostly a unstable -> testing migration issue, and not something
> users dist-upgrading from oldstable to stable will face.

Agreed on that. I really consider unstable->testing update problems
critical. Updates need to work through	dist-upgrade  and nothing else.

> My ideas (also based on past experience)
[..]
> - follow upstream SONAME bumps when they happen

That is happening (and has happened for 5.19, afair).

> - 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

That is the tricky part, due to the convolution of c++ symbols and
checks on internal versus external symbols. Honestly, I don't have a
good way, and reading all kind of stuffs from other deb devs about it,
it seems using symbols files for c++ sources are not really
recommendable.

But then, I don't have that much experience with it, and leave these
kind of decisions for Scarlett and others.

> - 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

Honestly, I don't see the need to go to that great length. If upstream
breaks things like this, then downstream has to adapt, too.
I just say "poppler" ... (breakage at every release, without bumps).

> 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.

I have no idea how this was done, and will most probably not implement
it.

> 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

Indeed.

> 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.

So let us return to the question I posed above: What do you suggest
*now* - and that means in the remaining short time we have?

Again, thanks a lot for your detailed comments and all the best

Norbert

--
PREINING Norbert                              https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13