While trying to upgrade net-snmpd to see whether it would solve an annoying log-spamming problem, I found it would only build on 32-bit, complaining of a missing file (libutil.h) on 64.
Further investigation revealed that perl for 64-bit had been built on a machine with libbsd-devel installed, which had caused perl to grab that as a dependency for perl-devel, although there was no mention of this package in the spec file.
Looking in /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE/perl.h, the inclusion of libutil.h is commented "/* setproctitle() in some FreeBSDs */". If I understand that correctly, this dependency is just to provide a single function which is sometimes useful when running on FreeBSD, which of course, we're not.
If I install libbsd-devel (which pulls in libbsd as well), net-snmpd will build on 64-bit, but this package is not really a dependency of net-snmpd but of perl-devel because of the peculiar circumstances in which perl was built. Adding a BuildRequires to net-snmpd would get it built, but at the expense of installing two unnecessary packages and leaving others building packages depending on perl-devel to repeat the same head-scratching exercise.
Now for my question. What is the best way to resolve this:
1. Add "BuildConflicts: libbsd-devel" to perl to ensure it is not built on a machine with this package installed,
2. Add "BuildRequires: libbsd-devel" to perl and "Requires: libbsd-devel" to the devel section,
3. Patch perl to replace its Configuration scripts with ones which don't assume it's being built for use on the same machine, but for distribution (this last one would be beyond my ability - the others might be if other perl packages - and there are hundreds - assume the same dependency), since the way those scripts work is to examine what's installed with all sorts of files and build for the specific environment?
Without one of these solutions we won't get consistency when perl-devel is rebuilt or installed on a new machine.
Help! I don't even want to package perl - just use it!
