Description of problem: rpmdev-rmdevelrpms fails because xbae requires automake. It should be a buildrequires and the ac_find_xbae should get installed with the -devel package. The ac_find_motif should get installed with lesstif-devel (the same file is in lesstif's tarball under scripts/autoconf/) but that's a separate issue. I might file a bug against that. Version-Release number of selected component (if applicable): xbae-4.60.4-4.fc6 How reproducible: 100% Steps to Reproduce: 1. Install xbae 2. run rpmdev-rmdevelrpms Actual results: ...but removal would cause unresolved dependencies: xbae-4.60.4-4.fc6 requires automake Expected results: rpmdev-rmdevelrpms works Tobias
(In reply to comment #0) > Description of problem: > rpmdev-rmdevelrpms fails because xbae requires automake. > It should be a buildrequires and the ac_find_xbae should It is not a BuildRequires, there is no need for automake at build time. > get installed with the -devel package. It is installed in the -devel package, and it is a Requires for the devel package, for the %{_datadir}/aclocal/ directory ownership. I mistakenly made it a Requires for the main package instead of the -devel one, thanks for the heads-up. Should be fixed in 4.60.4-5. > The ac_find_motif should > get installed with lesstif-devel (the same file is in lesstif's > tarball under scripts/autoconf/) but that's a separate > issue. I might file a bug against that. It is part of lesstif-devel. # rpm -ql lesstif-devel | grep m4 /usr/share/aclocal/ac_find_motif.m4
Oups, I must have been really tired when I filed this bug. Thanks for sorting this out so quickly :) I'm still a bit confused about -devel requiering automake just for the aclocale dir. On my system, of all the other packages that put files there only lesstif-devel requires automake. Should all the others require it as well, or is xbae+lesstif somehow at fault? Tobias
I don't know what is the proper fix. There is something clearly wrong with putting something in aclocal dir without owning it nor requiring automake, since the aclocal dir is unowned in those cases. The 3 possibilities are owning the aclocal directory, depending on automake or depending on the directory itself. Trouble with depending on the directory is that it may lead to a bogus dependency on a devel package owning it, so I think the best choices are owning the aclocal directory or depending on automake. Another possibility would be to have the aclocal dir in some filesystem only package, but that's not something I have much power on. I hope that someday, when directory owning is really enforced, this issue and similar ones will be fixed/decided once for all.