Hide Forgot
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 ./configure ... 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.