Policy for Dependencies

Mon Oct 19 16:53:39 UTC 2015

Hi,

> On Sunday, 18 October 2015 14:45:43 BST David Faure wrote:
>> On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote:
>> > Lets see what David thinks about all that.
>> 
>> First: thanks everyone for waiting for my input, I appreciate that (I'm just
>> one more voice though, no dictatorship here).
> 
> But a well-respected voice :-). Also, you're the closest thing we have to a
> "frameworks co-ordinator", in your role as release manager.
Yeah ;=)

> 
>> The various global switches that have been suggested had unintuitive naming,
>> so I will describe my thinking about them by using descriptions instead of
>> actual names:
>> 
>> 1) A global switch "skip anything marked as optional" would be a very bad
>> idea, it would even skip stuff that *is* available. I *think* this wasn't
>> suggested, but I wanted to mention it just in case.
> 
> There may be a certain temptation to view it as an easy solution for those who
> want to build a stripped-down version of (part of) Frameworks without
> accidentally dragging in deps that happen to be on the builder's system. In
> practice, however, anyone doing this would probably want close control over
> the deps (rather than stripping out everything optional), and CMake already
> provides that via some magic variables to disable searching for packages.
+1
Such a switch is not needed, if stuff is optional there are enough ways
to ensure it is not used in a sane way.

> 
>> 2) A global switch "everything that can be optional, is now optional" sounds
>> strange to me too. If it's optional, it's optional. (The description for
>> the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this might lead to a
>> loss of functionality". Well, that is *always* true when an optional
>> dependency isn't found - otherwise it would be useless). Really, is there
>> any sense in saying that a dependency is optionally optional?
>> 
>> 2.1) I can see how the purpose was to let the default build be "with as many
>> dependencies as possible". But for that maybe we can have a global switch
>> for "fail if something optional was not found", for distros (and CI) to
>> make sure they have *everything* enabled. Would this actually work for
>> distro packagers? Do they have *all* the dependencies available?
> 
> I think it's more about the distinction (vague as it may be) between
> "optional" and "recommended" dependencies (FeatureSummary provides this
> distinction, but we very rarely use it). I think the idea is to be able to
> distinguish between "if this exists on your system, we will attempt to
> integrate with it" dependencies and "if we don't make use of this, a feature
> might be missing that users would expect to be there".
> 
> (As a side note, we may have that package A depends on package B *with
> optional feature C*. In particular, bits of Plasma may well require or
> recommend that certain Frameworks are built with certain features enabled that
> rely on optional dependencies. This is fine - see KArchiveConfig.cmake.in for
> how to deal with that.)
> 
> I think the idea was essentially to have an easy way to cause a build failure
> if the recommended dependencies weren't found (possibly with the default being
> the failure mode).
> 
> I'm fairly on the fence about the usefulness of that, TBH, particularly if
> your idea below solves the "bug reports from feature-deprived builds" issue.
> 
>> An argument was made that optional deps create more work for maintainers,
>> who can't know, in bug reports, whether the dep was enabled or disabled
>> (i.e. more configurations to handle). That is true. The solution isn't
>> however to make everything mandatory. So we should solve this, after
>> accepting the existence of optional deps. One random idea could be
>> (automatically) installing a file, from each framework, with the list of
>> optional deps that were found. Then when handling bug reports you can ask
>> for that file -- or drkonqi could grab them all and concatenate them in a
>> readable way.
> 
> This seems like a useful thing to do, especially when automating it via
> DrKonqi.
The way KArchive does that is interesting.
Would this be e.g. a way to say: Ok, we can compile configwidgets without KAuth
if we skip the KCM part and then write that inside our config?

Atm e.g xmlgui has tremendous many dependencies that are often not needed.
Boudewijn made a request to make more stuff optional which is imho a bit too intrusive
but with not that much work some stuff could be removed:

https://git.reviewboard.kde.org/r/125530/

I would in addition see value in a "this is recommended" switch, that leads
to compile failure if recommended stuff is not there or the switch is toggled off.

That way, even without David's proposed improvements for the bug reporting, I and
others could make more stuff optional, like audio in notifications, without it leading
to bugs for the "standard" case of distro packages.

> 
>> 3) A global switch for a dependency, like "don't even look for dependency A
>> in any of the frameworks" brings nothing IMHO. If it's optional and not
>> found, we compile without.
> 
> As in my note in (1), I don't think this is something we should be setting,
> but rather than builders should be setting if necessary - CMake provides all
> that infrastructure, so we don't need to do anything (with the exceptional
> case of X11 on Mac, as you noted).
Yep, and btw., the way we do that at the moment for Mac is very strange.
If you pass CMake no arguments, you get a strange warning that you compile
without X11 support and might either turn this warning of or X11 on.
I would prefer no such info at all, given non-X11 is there the only official way
to go, Qt not even ships any X11 backend per default. (that you can turn it on
with the var is nice, but should not be promoted)

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234