Policy of explicit disabling of package features
Hi,
I'm using the pulseaudio packaging as the starting point to learn about OE packaging. I'm trying to understand why everything is done as it is done, and my current focus is on pulseaudio's EXTRA_OECONF:
EXTRA_OECONF = "\
--disable-hal-compat \
--disable-orc \
--enable-tcpwrap=no \
--with-access-group=audio \
--disable-openssl \
--disable-xen \
--with-database=simple \
--without-fftw \
--without-zsh-completion-dir \
--with-udev-rules-dir=`pkg-config --variable=udevdir
udev`/rules.d \
ac_cv_header_valgrind_memcheck_h=no \"
I'm trying to understand the reason for each of those options. One question that I had was that why are some features explicitly disabled, when they should get anyway disabled automatically due to missing dependencies. I found out from the git logs that at least some of them are explicitly disabled, because the configure script may randomly find some dependencies installed even if they are not listed in DEPENDS, due to other packages pulling them in.
This then raises the question that what the policy of explicit vs. implicit disabling is, and also what the policy *should* be. It seems that the current policy is that things are explicitly disabled only after someone has run into problems with the non-determinism. Is that correct?
It seems to me that a better policy would be to always explicitly disable *all* features that have external dependencies that aren't listed in DEPENDS. That kind of policy should reduce these non-determinism issues. Full compliance with such policy may not be feasible to achieve, since it requires great care to check for new optional dependencies whenever updating to new upstream versions, but I hope that at least "pre-emptive" patches that add explicit feature disabling will be accepted even before anyone has run into actual problems.
Signature · 1 line
Tanu
Quoted 8 lines · Tanu Kaskinen
It seems to me that a better policy would be to always explicitly disable *all* features that have external dependencies that aren't listed in DEPENDS. That kind of policy should reduce these non-determinism issues. Full compliance with such policy may not be feasible to achieve, since it requires great care to check for new optional dependencies whenever updating to new upstream versions, but I hope that at least "pre-emptive" patches that add explicit feature disabling will be accepted even before anyone has run into actual problems.
This is the policy, if its not in DEPENDS, it shouldn't be using it.
As you say, adherence to that policy can be tricky, its something we try and improve over time. Where we do find issue we fix them as you've seen from the patches. We do have better detection of these issues than we've ever had before.
Cheers,
Richard
Quoted 11 lines · Richard Purdie
Quoted 8 lines · Tanu Kaskinen
It seems to me that a better policy would be to always explicitly disable *all* features that have external dependencies that aren't listed in DEPENDS. That kind of policy should reduce these non-determinism issues. Full compliance with such policy may not be feasible to achieve, since it requires great care to check for new optional dependencies whenever updating to new upstream versions, but I hope that at least "pre-emptive" patches that add explicit feature disabling will be accepted even before anyone has run into actual problems.
This is the policy, if its not in DEPENDS, it shouldn't be using it.
Ok, excellent! I'll make a patch that adds some --disable-foo options to pulseaudio.inc that are currently missing.
Signature · 1 line
Tanu