How to handle KDE not respecting YOUR distros requirements?

[Martin Steigerwald]

On Montag, 28. März 2016 03:49:24 CEST Thomas Pfeiffer wrote:
> > If Plasma is not one stack, I think some guidance for distributions would
> > be beneficial. I think that currently Debian Qt/KDE team tries to package
> > as much as they can (which is *lots*).
> 
> So now it looks like we have at least contributors from two distributions
> who  would like more guidance. Let's hear what others have to say, too.

Please do not read my oppinion as being official for the Debian Qt/KDE team. I 
helped a bit here and there, lurk on the IRC channel, but the actual packaging 
work is done by others.

I invited them to this list, lets see.

What I gathered so far, that the actual packaging isn´t that much of an issue. 
Maxy automated most of this and has scripts that fetch upstream source and 
build packages in batch – some days he uploads 50+ packages into Debian within  
a few hours. Yet where it comes short and where the team wants help is – I 
actually asked Maxy about it: Testing the compiled packages, triaging bugs. 
Currently often packages are just build / install tested, from what I 
gathered. Thats why I try to help in that area. In the transition period from 
GCC 4 to 5 and KDE SC 4 to Plasma / KF 5 quite some time often dependencies 
have been missing to make things work. And often it appeared to me that 
maintainers where unaware that these dependencies are required until users 
reported about missing functionality. I don´t have the Debian bug report 
numbers at hand but I can search some examples if need be.

Right now its a bit difficult for me tough to help with testing Debian 
packaging, since most of the new packages are in experimental, waiting for 
transition of Qt 5.6.1 from experimental into unstable – for some reason 
Lisandro and others do not like to migrate 5.6.0 into unstable, as far as I 
gathered due to some bug(s). I also help KDEPIM upstream testing a bit and so 
have self-compiled KDE frameworks + KDEPIM, so its not that easy for me to 
test things with stock distro state at the moment. I´d love to be able to 
build KDEPIM on top of distro framework packages, so I can just have KDEPIM in 
a newer state and everything else in distro state, but back then I have been 
told that may or may not work, cause KDEPIM git master may require stuff from 
newer framework git stuff as well. Also upstream devs modularize most of 
KDEPIM into frameworks as well currently, so it becomes more and more 
difficult to just build KDEPIM – and not all of KDE Frameworks 5 – on top of 
distro stuff. Due to some version conflict / bug I even can´t start a new 
Plasma session unless I temporarily rename the directory with self-build KDE 
Frameworks + KDEPIM. After I logged in, I can activate my self-build stuff 
again, but during login it just hangs and fades to black at a moment when it 
is activated via the script in ~/.config/plasma-workspace/env or so. After I 
didn´t see anything obvious in ~/.xsession-errors I gave up on debugging it 
and just hope that with newer Debian framework packages my self-compiled 
frameworks + KDEPIM will not stop session login from working anymore. Also I 
need to use self compiled KDEPIM due to backwards incompatible changes in 
Akonadi + using 15.12 KDEPIM + Akonadi packages from Debian experimental would 
uninstall KMyMoney which I use a lot due to removal of Akonadi 4 related 
packages. To make that story short: My own current setup is quite a mess and 
that does allow for defining a clear setting for testing.

From that I personally got the impression that the current Plasma 5 + ton of 
frameworks state with the current state of documentation what needs what in 
which version does make it more difficult to ensure a sane state of the build 
packages.

For Debian the biggest challenge currently appears to be to get all the new 
stuff into unstable to make it easier to test for users. And since this is 
like so for some months already, I am pretty sure the Qt/KDE team faces some 
challenges here. From what I gathered the next thing is to have Qt 5.6.1 in 
unstable as a prerequiste for pushing updated framework and plasma packages 
there.

I do consider testing things in a VM, but its challenging to make real 
production data for testing available to the VM. My laptop SSDs do not have 
enough space for example to copy over my local maildir folders for KDEPIM for 
example. At least for basic desktop stuff I can test it tough. Still having 
things in Debian experimental makes it more difficult to ensure I have all KDE 
Frameworks + Plasma packages upgraded. In KDE SC 4 times I mostly could look 
at the usual metapackages, but with KDE Frameworks the amount of packages to 
check for becomes confusingly high.

Thanks,
-- 
Martin