Policy for Dependencies

[Alex Merry]

On 2015-10-19 17:53, Christoph Cullmann wrote:
>> On Sunday, 18 October 2015 14:45:43 BST David Faure wrote:
>>> 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?

Yes, you could do that, and then Plasma, for example, could check the 
variable that was set and complain if KConfigWidgets had been compiled 
without the KCM. Downstream packages could also use FeatureSummary to 
say something like "KFoo wasn't compiled with feature X, therefore 
feature Y will be disabled for this package".

> 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.

Well, this is the question: is it worth the extra complexity of 
supporting such a switch (and it will introduce a reasonable amount of 
complexity) if we have a way of including feature/dependency information 
in bug reports?

>>> 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)


I was playing it safe, given the behaviour change. I'm open to removing 
the warning a few releases down the line. Ideally, the warning would 
only be shown if X would otherwise be found, but that's not really 
practical.

Alex