Description of problem:
The popt package ships a C header file /usr/include/popt.h file.
This popt.h file is detected by any package's configure script.
As libpopt.so is required by a LOT of other packages, one
cannot just remove the popt package to test the
"if-no-popt.h-detected" path of the configure script.
If the popt.h file was in a separate popt-devel package, one could just
uninstall that one, leaving libpopt.so and all
Version-Release number of selected component (if applicable):
popt-1.10.2-15.2 from rpm-4.4.2-15.2.src.rpm
So don't remove the popt package, do this instead:
mv /usr/include/popt.h /usr/include/popt.h-ORIG
mv /usr/include/popt.h-ORIG /usr/oinclude/popt.h
Good idea. This makes automatic build scripts so much more straightforward. :-/
Removing popt-devel while building will have at least as significant an effect on other processes using a
build tree as renaming the files for the purposes of automated build scripts.
Besides, you said for testing a (presumably lightly traveled) "if-no-popt.h-detected" path of the configure
script. Surely that path does not need testing more than occaisionally.
And even if popt-devel were to be created, there's gazillions of systems that will break
your configure testing scheme no matter what, its not like everyone is gonna suddenly upgrade
popt to use a popt-devel split as you suggested.