Bug 807767

Summary: Latest cups-libs doesn't provide libcups.so.2
Product: [Fedora] Fedora Reporter: Gwyn Ciesla <gwync>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ffesti, jnovy, jpopelka, mtasaka, pmatilai, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-29 08:54:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gwyn Ciesla 2012-03-28 16:34:01 UTC
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!

Comment 1 Mamoru TASAKA 2012-03-29 04:42:20 UTC
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.

Comment 2 Mamoru TASAKA 2012-03-29 04:50:15 UTC
(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.....

Comment 3 Panu Matilainen 2012-03-29 08:17:44 UTC
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.

Comment 4 Panu Matilainen 2012-03-29 08:54:47 UTC
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.

Comment 5 Mamoru TASAKA 2012-03-29 10:43:27 UTC
Once I rebuilt cups with new rpm. For filtering provides issue, I will leave it to cups maintainer for now.

Comment 6 Tim Waugh 2012-03-29 11:11:56 UTC
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.