Bug#824495: debian-policy: Source packages "can" declare relationships
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
Reply to: