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

Norbert Preining norbert at preining.info
Tue Dec 8 01:12:03 GMT 2020


Hi Pino, Patrick, Scarlett,

On Mon, 07 Dec 2020, Pino Toscano wrote:
> - too broad solution

Ok, opinion.

> - lots of boilerplate in many packages (30+), even in case where there
>   is no need for it

That should have been taken care of by the plasma.mk/injectdependencies.
A newer version based on provides plasma-base-5-20 could probably even
more simple.

> - it does not solve the issue with out-of-Plasma packages using Plasma
>   libraries

That is true.

Concenring your question list:

> - what is the problem?

mixing of packages from different releases

> - how does the proposed change solve the issue?

By depending on a versioned package.

> - how can be the proposed use case be tested

I have made tests by updating from stable with the proposed changes:
- install package in stable
- update sources
- update only that one package
- check that all other plasma package are updated to the same version
Done that, reported it.

> - does the proposed change conflict with any other existing use case?

Not that I know.

> Well, it depends on how kscreenlocker changed in 5.20 :)
> Did you check it so far?

There are the following symbol changes going from 5.19 to 5.20

* kwayland-server
  A huge mess of added/removed symbols (changes to about 700 symbols AFAIR)
  Since this is new without reverse dependencies outside plasma, I don't
  see the need to do something about it, but please correct me.

* kwin
  both libkwineffects12a and libkwinglutils12 gained several symbols,
  but both lost
	- _ZZN4KWin10connectionEvE5s_con at Base 4:5.1.95+git20150122
		KWin::connection()::s_con

* libksysguard
  libksysguardsensorfaces1 gained some symbols and lost
	- _ZN9KSysGuard20SensorFaceController7Private14createConfigUiERK7QStringRK4QMapIS2_8QVariantE at Base 4:5.19.4
		KSysGuard::SensorFaceController::Private::createConfigUi(QString const&, QMap<QString, QVariant> const&)
	- _ZN9KSysGuard20SensorFaceController7Private9createGuiERK7QString at Base 4:5.19.4
		KSysGuard::SensorFaceController::Private::createGui(QString const&)
	- _ZN9KSysGuard20SensorFaceController7PrivateC1Ev at Base 4:5.19.4
		KSysGuard::SensorFaceController::Private::Private()
	- _ZN9KSysGuard20SensorFaceController7PrivateC2Ev at Base 4:5.19.4
		KSysGuard::SensorFaceController::Private::Private()
  libprocesscore9 gained some symbols and lost
	- _ZN9KSysGuard17ProcessController7Private14localProcessesE at Base 4:5.18.90
		KSysGuard::ProcessController::Private::localProcesses
	- _ZN9KSysGuard21ProcessAttributeModelC1EPNS_17ExtendedProcessesEP7QObject at Base 4:5.18.90
		KSysGuard::ProcessAttributeModel::ProcessAttributeModel(KSysGuard::ExtendedProcesses*, QObject*)
	- _ZN9KSysGuard21ProcessAttributeModelC2EPNS_17ExtendedProcessesEP7QObject at Base 4:5.18.90
		KSysGuard::ProcessAttributeModel::ProcessAttributeModel(KSysGuard::ExtendedProcesses*, QObject*)
  other libs only gained symbols

* plasma-workspace
  libtaskmanager6abi1 lost one symbol
	- _ZZZN15KMimeTypeTrader16preferredServiceERK7QStringS2_Ed_NKUlvE_clEvE15qstring_literal at ABI_6_1 4:5.17.5
		KMimeTypeTrader::preferredService(QString const&, QString const&)::{default arg#1}::{lambda()#1}::operator()() const::qstring_literal
  others only gained symbols


Suggestions welcome

> If that's OK for you, I can upload these changes this weekend, when the
> buildd queue is slightly more empty (right now there are the
> "drop py3.8" rebuilds).

Sure enough, please go ahead!
(I hope I speak for Scarlett, too!)

> What I consider "the other half" of this tooling is... manual checking
> the differences between the old version (5.19.x) and the new one
> (5.20.x). Yes, it's a manual work, but it easily allows to spot these

You mean diffing the sources ... well, I leave this to someone who wants
to do it.

> > I just say "poppler" ... (breakage at every release, without bumps).
> 
> Bad example: poppler always bumps SONAME together with its API and ABI
> of the core (private) library.

No, you are wrong. poppler broke TeX Live builds about a zig times due
to changes without version bump. I can dig up all the reports if you
want. That was one of the reason I started again to use the TeX Live
internal poppler, since the one in Debian is happily breaking things.
Admitted, it hasn't changed in the last year, but before that several
times.

> Sandro described it on the list:
> https://alioth-lists.debian.net/pipermail/pkg-kde-talk/2020-November/003171.html

Sandro's option 2 is very much what I have implemented in the pull request,
besides that he is doing only for shared libraries.

Also option 3 is probably a similar approach in reverse to my
plasma-base approach.

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



More information about the pkg-kde-talk mailing list