On Mon, Jul 23, 2018 at 10:28 PM <mcatanz...@gnome.org> wrote: > On Mon, Jul 23, 2018 at 8:27 PM, Josh Boyer <jwbo...@fedoraproject.org> > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/XJI7GUKAS4IQLWN2H3MCPKTGQLSW5DBA/
