On Tue, Jul 24, 2018 at 3:43 PM Stephen Gallagher <sgall...@redhat.com> wrote:
> 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 has anything to do with system-wide changes. It affects only components which use meson. However I might submit self-contained one if you feel strongly about this. > 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/ > -- -Igor Gnatenko
_______________________________________________ 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/QSPKRVM7GVWKQPF2FSC3XPNNGZCDSS5T/
