On Sat, 10 Nov 2018 at 19:29:03 -0700, Sean Whitton wrote: > On Thu 08 Nov 2018 at 02:51PM GMT, Ian Jackson wrote: > > (ii) output packages with additional features or functionality. > > Such additional features MAY imply additional functional runtime > > dependencies, which then SHOULD be represented in the output > > packages' metadata. In this case the additional packages > > SHOULD NOT be declared in Build-Conflicts. > > Do we really want (ii)? It seems like a recipe for all sorts of > confusion. Do any packages currently work like that?
I don't have any concrete examples, and I'd argue that they are not best-practice, but they almost certainly exist in the archive. This will happen whenever an Autoconf package has a feature enabled by an "automagic" dependency, the maintainer has not enabled the feature for all Debian users by adding its required package to B-D or explicitly enabling it with --with-foo or --enable-foo (either deliberately, or because they didn't notice the feature being added), and the maintainer has also not explicitly disabled it with --without-foo or --disable-foo. For instance, dbus has optional support for using AppArmor policy to decide which messages to deliver. If its maintainer hadn't noticed that feature being added, then it wouldn't have B-D: libapparmor-dev or ./configure --enable-apparmor, but it also wouldn't have ./configure --disable-apparmor, resulting in the upstream default behaviour (AppArmor-related features enabled if and only if libapparmor-dev is installed). I think the best practice is for maintainers to notice new features being added, make a deliberate decision on what to enable (in an architecture- or kernel-specific way if appropriate), and use the equivalent of --disable-apparmor for any feature we don't (yet?) want to enable. smcv