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

[Heiko Becker]

Hello,

On 03/22/16 10:07, Richard Brown wrote:
> On Tue, 2016-03-22 at 03:31 +0100, 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.

> 
> Luca already expressed our displeasure with having to dig around cmake
> results to figure out what additional dependencies are required

This is something I really disagree with. I have to look at changes in
cmake files anyway, since they are most reliable way to track changes in
dependencies and version requirements. Additionally looking at some
README files is just additional work, or at least unnecessary noise for
me, especially since they tend to become outdated, whereas cmake files
are at least build tested.

As a packager of a source based distro, I would also like to say that I
welcome a certain, sensible set of options to customize the build
process. I'm not speaking of making support for libpng or SSL optional,
but the optional NetworkManager dependency of plasma-workspace for
example, which avoids pulling in a huge dependecy tree for some people
with little gain for them. Thank you for already doing that.

Best regards,
Heiko