GNOME Bugzilla – Bug 755063
build: Drop hardcoded requirements on Linux
Last modified: 2015-09-16 18:33:10 UTC
Created attachment 311368 [details] [review] 0001-build-Drop-hardcoded-requirements-on-Linux.patch The goal of the GNOME Continuous build is not to be a full distribution with the costs and benefits of that model. It's intended to be a minimal but still useful continually delivered and tested system. At the moment, we don't have Samba in the build, and while we could add it, we don't have any testing for printing right now. The original commit didn't include any rationale for this.
(In reply to Colin Walters from comment #0) <snip> > The original commit didn't include any rationale for this. The discussion was done in Bugzilla. The Settings application isn't a bag of bits. I'm not interested in supporting, on Linux, an application that won't have all the necessary dependencies at build time, leading to missing functionality in distributions. libsmbclient is required for Printers, libwacom is necessary for the Wacom panel, NetworkManager is required for the Network panel, etc.
(In reply to Bastien Nocera from comment #1) > (In reply to Colin Walters from comment #0) > <snip> > > The original commit didn't include any rationale for this. > > The discussion was done in Bugzilla. The Settings application isn't a bag of > bits. I'm not interested in supporting, on Linux, an application that won't > have all the necessary dependencies at build time, leading to missing > functionality in distributions. A much more common way to do that is to have features enabled by default, and require passing --disable-foo explicitly to disable things. Would that be OK?
(In reply to Colin Walters from comment #2) > (In reply to Bastien Nocera from comment #1) > > (In reply to Colin Walters from comment #0) > > <snip> > > > The original commit didn't include any rationale for this. > > > > The discussion was done in Bugzilla. The Settings application isn't a bag of > > bits. I'm not interested in supporting, on Linux, an application that won't > > have all the necessary dependencies at build time, leading to missing > > functionality in distributions. > > A much more common way to do that is to have features enabled by default, > and require passing --disable-foo explicitly to disable things. Would that > be OK? No, because that would still allow Linux distributors to disable parts of the functionality. I'm not interested in that. The only reason those are detected right now is because some of the functionality doesn't work on non-Linux, and we still try to support that.
(In reply to Bastien Nocera from comment #3) > No, because that would still allow Linux distributors to disable parts of > the functionality. I'm not interested in that. I don't understand why - can you explain more? It seems like 98% of the pain is maintaining optional build parts which is already done. Keep in mind in return for having printing optional, I help maintain GNOME Continuous, which is reliably and continuously building gnome-control-center, among many other projects.
For now: https://git.gnome.org/browse/gnome-continuous/commit/?id=9bcbede6fdf8efc6a00f6364bcabba102ef3d4ca
> The original commit didn't include any rationale for this. Amongst others: https://bugzilla.gnome.org/show_bug.cgi?id=700149#c7 https://bugzilla.gnome.org/show_bug.cgi?id=700145#c2 https://bugzilla.gnome.org/show_bug.cgi?id=700145#c8 https://bugzilla.gnome.org/show_bug.cgi?id=727201#c1 https://bugzilla.gnome.org/show_bug.cgi?id=728318 https://bugzilla.gnome.org/show_bug.cgi?id=728879#c1 I'm not interested in reverting back to that. Let me know if I can help bring libsmbclient into gnome-continuous instead.
It's possible, but back behind a general OpenEmbedded rebase. But the more things that are pulled in, the more GContinuous becomes a distribution, and that's an explicit non-goal. For now I guess we'll just close this and live with a patch.