On Mon, Jul 23, 2018 at 10:28 PM <mcatanzaro@xxxxxxxxx> wrote:
On Mon, Jul 23, 2018 at 8:27 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx>
wrote:
> My biggest objection here is that it blindly enables things, which
> continues to make our package set a web of inter-dependencies and
> makes any attempts at minimization harder. I don't think we should
> default to building everything in here. I understand autotools might
> do that, but I wouldn't necessarily call autotools a best practice to
> begin with...
It's a bit confusing, but Igor is proposing that we *disable* auto
feature detection by passing -Dauto_features=enabled. Um, what? Yes,
the options are enabled, auto (default), and disabled, where both
enabled and disabled turn off auto feature detection. enabled is used
to fail the build whenever an auto dependency is missing, and disabled
is used to allow the build to proceed without that feature.
-Dauto_features=auto is the meson default, and it's what we currently
suffer with autotools: features get silently enabled or disabled
depending on which BuildRequires are present in the spec file. This is
the status quo, and it's a disaster. Auto dependencies are good if
you're building packages locally and don't want to install unnecessary
dependencies (hence a good default behavior), but very bad if you're a
Linux distribution building packages for other people to use and now
have a broken or inferior package due to a desireable dependency being
disabled by mistake. I'm pretty sure there's no argument for keeping
this behavior when building Fedora packages.
We had originally forbidden the use of meson's auto features in GNOME
due to this problem (the automagic dependencies problem [1]), which
annoyed the Meson developers and led to the creation of this
-Dauto_features option. Now it's safe to recommend using auto features,
because we assume distros will build with -Dauto_features=enabled. With
this setting, if you want to disable a feature that's recommended by
upstream, you'll now have to explicitly disable it, which is surely
what we want to avoid features disappearing by mistake.
Then on the other end of the spectrum, -Dauto_features=disabled would
disable all auto features... that would make packagers responsible for
constantly monitoring the upstream feature set with every release and
making choices about what to enable or disable. It sounds like you
might be advocating this option, but that does not seem at all
practical to me. Packagers sometimes know better than upstream which
features should be enabled in Fedora, but not usually. And packagers
might sometimes audit the upstream feature list after new releases to
see if new features should be enabled... but that seems like a rarity
to me. If we use -Dauto_features=disabled, a bunch of important
features will go missing, and Fedora will suffer from that. So let's
trust upstream by default, and override where it makes sense.
Thank you for the detailed explanation, Michael. That does make it much clearer. So the effect of this change (which should probably be proposed as a System-Wide Change to FESCo, since it affects the default build flags[*]) is to make the build deterministic by not quietly suppressing some of the output if their build dependencies are unsatisfied. This then forces packagers to use explicit enablement and disablement flags if they want to diverge from upstream.
I don't think this will really have a meaningful impact on the dependency creep, other than to make it more accurately represent the upstream preferred state. We can then choose to diverge as needed.
I'm in favor of this change, but as I said above, I'd like to see this go through the Change process since it potentially impacts anything using meson to build.
[*] This is minimally-invasive, so I'd be willing to consider it as a late proposal for F29.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/XJI7GUKAS4IQLWN2H3MCPKTGQLSW5DBA/
