GNOME Bugzilla – Bug 697478
Make gnome-online-accounts, colord and bluetooth supports optional
Last modified: 2013-04-08 11:40:10 UTC
Created attachment 240875 [details] [review] gnome-control-center-3.8.0-optional-r1.patch We are carrying this patch downstream on Gentoo to allow people skip some unwanted dependencies in some cases, only for let you know its existence to let you commit if wanted :)
gnome-online-accounts and colord are hard dependencies of gnome-control-center and Bluetooth is only disablable on systems that don't support Bluetooth (s390* on Linux, as it lacks a USB stack, and other non-Linux). They're not optional on purpose. I'd like you to remove this patch from Gentoo, it just makes upstream's life (hence mine) harder.
Sorry but these patches are done as a request from our user base and they are not going away for as long as we can maintain them. If you refuse to integrate them, well, that's more work for all source based distribution, but I admit we are not that many. Plus, our dependency system is clear enough to ensure our users figure out that they need to enable bluetooth if they want bluetooth support.
Sometimes you need to do what your users need as opposed to what they want. If the patches aren't going away, the upstream support for Gentoo will be. I have little time for picking apart our own attempts at making a coherent environment.
(In reply to comment #1) > gnome-online-accounts and colord are hard dependencies of gnome-control-center > and Bluetooth is only disablable on systems that don't support Bluetooth (s390* > on Linux, as it lacks a USB stack, and other non-Linux). > Our ebuilds are the same for all platforms and architectures. We also carry this patch so that users of those platforms (such as s390) can explicitly disable things. Auto-detection of features does not work well with package management, as you know. Setting aside the other reasons mentioned, we would like it if you accepted this patch purely for this reason.
(In reply to comment #4) > (In reply to comment #1) > > gnome-online-accounts and colord are hard dependencies of gnome-control-center > > and Bluetooth is only disablable on systems that don't support Bluetooth (s390* > > on Linux, as it lacks a USB stack, and other non-Linux). > > > > Our ebuilds are the same for all platforms and architectures. And they don't carry enough information to make disabling bluetooth possible on those platforms that don't support it? > We also carry > this patch so that users of those platforms (such as s390) can explicitly > disable things. They shouldn't have to explicitely disable things. The target platform can be detected, and the support disabled. >Auto-detection of features does not work well with package > management, as you know. This has nothing to do with package management. Bluetooth support should be compiled in on platforms that support it. It's not optional. Ditto color and gnome-online-accounts. This has nothing to do with package management. >Setting aside the other reasons mentioned, we would > like it if you accepted this patch purely for this reason. Those reasons aren't valid, sorry.
(In reply to comment #5) > > Our ebuilds are the same for all platforms and architectures. > > And they don't carry enough information to make disabling bluetooth possible on > those platforms that don't support it? > They do. They require configure switches to be passed, which this patch adds. > > We also carry > > this patch so that users of those platforms (such as s390) can explicitly > > disable things. > > They shouldn't have to explicitely disable things. The target platform can be > detected, and the support disabled. > Same as above. Specifically, the 'bluetooth' USE-flag is masked for the entire architecture, which causes --disable-bluetooth to be passed at build-time. Hence, we need this patch to make that work properly. > >Auto-detection of features does not work well with package > > management, as you know. > > This has nothing to do with package management. Bluetooth support should be > compiled in on platforms that support it. It's not optional. Ditto color and > gnome-online-accounts. This has nothing to do with package management. > The package management bits come in where we need configure switches to be able to enable/disable compilation support for a library. Explicit enabling and disabling of features is how source-based distributions ensure that the feature set compiled into an install is predictable. Relying on each configure script to auto-detect support for a library at build-time leads to chaos, as I'm sure you know. Auto-detection is only useful for users who are manually compiling a package.
(In reply to comment #6) > (In reply to comment #5) > > > Our ebuilds are the same for all platforms and architectures. > > > > And they don't carry enough information to make disabling bluetooth possible on > > those platforms that don't support it? > > > > They do. They require configure switches to be passed, which this patch adds. I'd really rather the configure checks were made in the configure script. > > > We also carry > > > this patch so that users of those platforms (such as s390) can explicitly > > > disable things. > > > > They shouldn't have to explicitely disable things. The target platform can be > > detected, and the support disabled. > > > > Same as above. Specifically, the 'bluetooth' USE-flag is masked for the entire > architecture, which causes --disable-bluetooth to be passed at build-time. > Hence, we need this patch to make that work properly. We shouldn't have a --disable-bluetooth configure option, this should be detected in the configure script, and not an option. > > >Auto-detection of features does not work well with package > > > management, as you know. > > > > This has nothing to do with package management. Bluetooth support should be > > compiled in on platforms that support it. It's not optional. Ditto color and > > gnome-online-accounts. This has nothing to do with package management. > > > > The package management bits come in where we need configure switches to be able > to enable/disable compilation support for a library. Explicit enabling and > disabling of features is how source-based distributions ensure that the feature > set compiled into an install is predictable. > > Relying on each configure script to auto-detect support for a library at > build-time leads to chaos, as I'm sure you know. Auto-detection is only useful > for users who are manually compiling a package. You're just exacerbating the misfeatures in the current configure script. To recap: - Bluetooth should auto-detect platforms on which the feature is unsupported and bail if the platform is supported and gnome-bluetooth unavailable - GOA and color aren't disablable.