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

Mon Dec 7 19:35:23 GMT 2020

First: Thanks Pino for the detailed review.

On Monday, December 7, 2020 1:01:23 AM MST Norbert Preining wrote:
> 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?
I think we are in a better state this release than last, as last release was 
several behind and hense the missed kscreenlocker etc.. I would like to follow 
what Pino suggests as he has the most experience. 
> 
> > 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?
Correct
> 
> > 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.

My experience is with single packages and not with a large package set
such as plasma :( This was quite an eye opener.

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

Yes, thank you Pino
Scarlett
> 
> 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

-- 
Scarlett Moore
gpg: 7C35 920F 1CE2 899E 8EA9  AAD0 2E7C 0367 B9BF A089
Software Engineer @ Blue Systems
Debian Maintainer developer in training.
Netrunner PM
KDE Developer
-------------- 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/e5a419cb/attachment.sig>