Bug 807767 - Latest cups-libs doesn't provide libcups.so.2
Latest cups-libs doesn't provide libcups.so.2
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-03-28 12:34 EDT by Gwyn Ciesla
Modified: 2012-03-29 07:11 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-29 04:54:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gwyn Ciesla 2012-03-28 12:34:01 EDT

Corresponding f17 build does.  This breaks installation of ghostscript in mock, which broke my lilypond build.


I thought a rebuild of ghostscript might be needed, but I didn't think this was intentional.

Let me know if I can help.

Comment 1 Mamoru TASAKA 2012-03-29 00:42:20 EDT
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 00:50:15 EDT
(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 04:17:44 EDT
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$}
# 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 04:54:47 EDT
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 06:43:27 EDT
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 07:11:56 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.