http://koji.fedoraproject.org/koji/buildinfo?buildID=310175 Corresponding f17 build does. This breaks installation of ghostscript in mock, which broke my lilypond build. http://koji.fedoraproject.org/koji/getfile?taskID=3940407&name=root.log I thought a rebuild of ghostscript might be needed, but I didn't think this was intentional. Let me know if I can help. Thanks!
Looks like cups-libs actually contains libcups.so.2, however with new rpm 4.10 (develop version), /usr/lib/rpm/rpmdeps -P does not find Provides: libcups.so.2. (Also on my F-16 i686 machine, when I setup rawhide mock chroot environ and chroot to it, and try /usr/lib/rpm/rpmdeps -P /usr/lib/libcups.so.2, it just hangs up...) Once asking rpm maintainer.
(In reply to comment #1) > Looks like cups-libs actually contains libcups.so.2, however with new rpm 4.10 > (develop version), /usr/lib/rpm/rpmdeps -P does not find Provides: > libcups.so.2. Actually I meant "it seems that" with new rpm 4.10.....
Right, it's a bug of sorts in the new rpm: as a side-effect of fixing up other bogosity, rpmdeps was changed not to take arguments from the command line anymore as depedency generators take the file names on standard input, not as command line arguments. However I see rpmdeps is even documented as 'rpmdeps [options] FILE...', and that's how the fedora filtering macros use it. I'll need to change that back then, will do shortly... However this also points a flaw in cups packaging: it should not use the fedora filter macros as that causes certain (minor in this case) multilib issues as the files are not "colored" properly. Use of the filter macros for "multilib packages" such as cups-libs is even prohibited in the fedora policy somewhere. From cups.spec: # Fix private-shared-object-provides # RPM 4.8 %{?filter_provides_in: %filter_provides_in %{php_extdir}/.*\.so$} %{?filter_setup} # RPM 4.9 %global __provides_exclude_from %{?__provides_exclude_from:%__provides_exclude_from|}%{php_extdir}/.*\\.so$ The filter_setup stuff switches the dependnecy generation to legacy mode which doesn't have a clue about the newer internal filtering. If the spec is to be shared across rpm 4.8 and 4.9 versions, the filtering should be conditionalized properly. As it is, the __provides_exclude_from thing does exactly nothing.
rpmdeps in rpm-4.9.90-0.git11505.9.fc18 accepts files as arguments again. Obviously cups needs a rebuild to address the missing provide.
Once I rebuilt cups with new rpm. For filtering provides issue, I will leave it to cups maintainer for now.
I wish you had waited for me to reply. I'd just tested a local build with the filter lines removed, and tried pushing it which of course failed. Those lines were originally put there by Remi Collet, and I have sent an email asking them to look at it. The answer is most likely to just remove those lines.