Welcome everybody! - What can we do for you?

[Martin Graesslin]

On Friday, March 4, 2016 8:22:48 PM CET H W Tovetjärn wrote:
> I referenced the wrong mailing list by mistake - the correct one is
> kde-distro-packagers at kde.org, thanks to Elvis Angelaccio for pointing
> out my mistake.
> 
> On 04/03/16 10:08, Martin Graesslin wrote:
> > For me as a dev I try to specify it through CMakeLists. Like having
> > explicit mandatory dependencies and good description of optional
> > features. Can you please explain where this falls short? Given your reply
> > I have a feeling that this isn't sufficient to notice what is really
> > needed. (And that's also my experience so far which results in make
> > everything mandatory).
> 
> Do these mandatory and optional dependencies translate into the "decent
> Plasma experience"?

I would say yes and in my opinion there is no such thing as an optional 
dependency. Optional only exist to not have hard requirements on a technology. 
E.g. logind vs consolekit. In such cases it's in my opinion the job of the 
distribution to pick the one it needs and also to make sure there is at least 
one. Taking KWin as an example: it has an optional build dev to udev. 
Obviously Linux distros should provide it. It's only optional to support BSDs.

Should we in such cases detect that we are being compiled on Linux and then 
turn it into a mandatory dependency? Would that help?

> What parts of Plasma make up this experience to
> begin with?

All packages released as Plasma. The only optional packages are those:
* marked as experimental (e.g. in 5.6 breeze-grub, breeze-plymouth, 
mediacenter)
* named addons (e.g. kdeplasma-addons)
* oxygen

Unlike frameworks we don't have metadata in our packages. Is that something 
which would help? Having a plasma-metadata.yaml file in each repo stating 
whether it's considered an experimental or optional package?

> Which ones do you want the users to use? Is the KDE PIM
> suite a part of it? 

KDE PIM is not part of Plasma and there is no dependency to KDE PIM. As Plasma 
devs we don't care what PIM technology our users use, be it KDEPIM, 
Thunderbird or just GMail webinterface.

> CMakeLists are something I can understand - either
> something is or it isn't. What I have a difficulty understanding is the
> vision or what you want to achieve because it's rather subjective. Could
> we get a list of criteria that translates into this by parsing and
> aggregating all the CMakeLists into a single document, and then go from
> there to make it more "human"?

I would say: every technology Plasma packages depend on needs to work at 
runtime. E.g. if there is a bluedevil package which depends on bluez, bluez 
needs to work. So to a certain way that's encoded in CMakeLists.txt ;-)

I see your point in having one combined resource for all dependencies of all 
packages. But I don't have an idea yet how to achieve it.

> I believe all of you whom I quoted are contributors to KDE and there is
> clearly something here that isn't in any CMakeLists I know of. While
> some of the points raised are highly subjective I suspect an underlying
> vision of what this "decent Plasma experience" would be like. While
> writing tests might be premature, I think that you may be able to do
> some brainstorming in a wiki article or on notes.kde.org. If you jot
> down all these things that you consider important, we could go from
> there to compile it into a more formal document.

Thanks for that summary. There is quite some useful input in it :-)

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/distributions/attachments/20160306/4f33b304/attachment.sig>