How to announce new optional dependencies? [was: What KDE would like distributions to do]

[Martin Graesslin]

On Thursday, March 24, 2016 7:15:17 PM CET you wrote:
> 2016-03-22 8:21 GMT+01:00 Martin Graesslin <mgraesslin at kde.org>:
> > On Tuesday, March 22, 2016 3:31:10 AM CET Matthias Klumpp wrote:
> >> One way to ensure new options get noticed is to enable them by default
> >> and make cmake fail in case they're not supported and - in that case -
> >> have the user explicitly disable them.
> >> With that, the *BSDs will have a couple of -DFROBNICATE=OFF lines in
> >> their package build scripts, but it also is immediately obvious that
> >> way which features they should ideally implement. And for Linux,
> >> distributions will investigate the build failure, find the missing
> >> depndency or other requirement and rather satisfy it instead of
> >> disabling the feature (and again, in that case we would have a visible
> >> flag in the build script).
> >> 
> >> It does make cmake scripts a bit more complex, but I think that's
> >> absolutely manageable.
> > 
> > hmm I fear that would making building from source for developers way more
> > difficult. It would turn all optional things into build errors and one
> > needs to hunt down the options to make it compile without them or figure
> > out why their distribution doesn't have it.
> 
> Isn't the premise that the features in question *should* be enabled,
> and that Linux distributions are providing these dependencies and the
> switches to disable features are mostly for *BSDs? Under these
> circumstances, having the build fail in case a missing dependency
> isn't there seems reasonable.

No, there are dependencies which make sense for a distro to install, but not 
for a dev. A dev might not need every dependency. Let's consider a simple 
example of a framework build dep I never installed:
HSPELL in sonnet

I will never need that, but a distro should have it. Why should we force devs 
to install it?

No, I don't want to make developers life more difficult because all optional 
deps are required.

Also we need to consider the needs which for example Krita constantly brings 
to our attention: more optional dependencies. Being able to not require e.g. 
KGlobalAccel everywhere, Krita doesn't need it, so let's not enforce it.

More strict required dependencies have also a cost. We need to find a middle-
ground.

> 
> > I just looked at the optional option in CMakeLists.txt of KWin and there
> > are many which are just to make devs life easier. E.g.:
> > * KF5Activities
> > * KF5DocTools
> > * XCB::ICCCM
> 
> Those should not be enabled by default and made to fail the cmake
> process then, because you wouldn't expect distributors to enable those
> features, right? If it's only very useful for developers, distros will
> usually not enable it (unless exceptions apply).

that was meant the other way around. Being able to not require them makes 
developers life easier. Why do I need documentation? Why do I need ICCCM (that 
was a rather pity state two years ago and is the reason for it being 
optional). 

> 
> > Then there are things like XCB::XInput2 which are not available on Debian
> > distributions (it's experimental upstream). Turning that to required by
> > default with a switch to make it optional makes the life of our devs on
> > Debian distributions way more difficult.
> 
> For us it would be just one more -DFOO=OFF switch in debian/rules -
> but again, is this a feature you expect all distributors to enable if
> possible? If so -> make it fatal and add a switch to disable the
> requirement if absolutely necessary. For a feature that's experimental
> upstream, I would expect that this is not something which should be
> always-on on distros, so leaving it completely optional until it
> enters the "features I want to have enabled everywhere, unless
> exceptional circumstances apply" set is fine, IMO.

That really depends. Personally I consider depending on that particular 
library a mistake on our side. But let's face it: there are such dependencies 
and they may bring a benefit/ Do we really need to enforce it then even if we 
know it will violate many distros policies?

E.g. should we depend on QWebEngine although we know what a hard time distros 
have to use it? Wouldn't it be better to have it optional and fall back to 
QWebKit if not available?

Overall I think with looking at what is required we are trying to solve the 
problem from the wrong side. We try to force it into the way it works with the 
existing tooling. I don't think that will work. Especially as it ignores all 
the reasons for optional build deps. I'm not a fan of optional build deps as 
that makes the build system more complicated. If it's optional there is a damn 
good reason for it. We shouldn't ignore that!

We need to look for another way. We need better tooling. CMake's output is 
obviously not sufficient. We need something which gives you better information, 
easier to parse and easier to understand why it's needed and whether it 
matters for your distro.

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/20160325/d6efe576/attachment.sig>