Bug 850628 - dependency/NEVR issues
dependency/NEVR issues
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libpng12 (Show other bugs)
18
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Petr Hracek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-21 23:23 EDT by Ralf Corsepius
Modified: 2014-01-21 18:23 EST (History)
10 users (show)

See Also:
Fixed In Version: libpng12-1.2.50-2.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-18 16:05:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2012-08-21 23:23:06 EDT
Description of problem:

libpng12-devel in rawhide and f18 has critical dependency/NEVR issues:

It does not install:

$ mock -r fedora-rawhide-x86_64 --install libpng12-devel
INFO: mock.py version 1.1.22 starting...
State Changed: init plugins
INFO: selinux enabled
State Changed: start
Mock Version: 1.1.22
INFO: Mock Version: 1.1.22
State Changed: lock buildroot
INFO: installing package(s): libpng12-devel
ERROR: Command failed: 
 # ['/usr/bin/yum', '--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/', 'install', 'libpng12-devel', '--setopt=tsflags=nocontexts']

================================================================================
 Package               Arch          Version                Repository     Size
================================================================================
Installing:
 libpng12-devel        x86_64        1.2.50-1.fc18          fedora        102 k
Installing for dependencies:
 libpng12              x86_64        1.2.50-1.fc18          fedora        173 k
 zlib-devel            x86_64        1.2.7-6.fc19           fedora         47 k

Transaction Summary
================================================================================
Install  1 Package (+2 Dependent packages)

Total size: 322 k
Total download size: 275 k
Installed size: 1.0 M
Please report this error in https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=yum
ERROR with transaction check vs depsolve:
libpng12(x86-64) = %{epoch}:1.2.50-1.fc18 is needed by libpng12-devel-1.2.50-1.fc18.x86_64
 You could try running: rpm -Va --nofiles --nodigest
Your transaction was saved, rerun it with:
 yum load-transaction /tmp/yum_save_tx.2012-08-22.05-18.3adKuf.yumtx
Comment 1 Tom Lane 2012-08-22 01:03:07 EDT
The message says to file this against yum, and indeed I do not believe there is anything wrong with libpng12's dependency declarations.
Comment 2 Ralf Corsepius 2012-08-22 01:25:05 EDT
Well, libpng12-devel's requires contain an explicit "%{epoch}" 

(Note: It contains the string %{epoch}, not the value you want it to contain):

# rpm -q --requires -p dl.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/Packages/l/libpng12-devel-1.2.50-1.fc18.i686.rpm 
warning: /var/ftp/pub/linux/mirrors/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/Packages/l/libpng12-devel-1.2.50-1.fc18.i686.rpm: Header V3 RSA/SHA256 Signature, key ID de7f38bd: NOKEY
/bin/sh  
/usr/bin/pkg-config  
libpng12(x86-32) = %{epoch}:1.2.50-1.fc18
libpng12.so.0  
pkgconfig(x86-32)  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
zlib-devel(x86-32)  
rpmlib(PayloadIsXz) <= 5.2-1

=> I haven't checked your *.spec, but this likely is bug inside of your spec.
Comment 3 Tom Lane 2012-08-22 01:36:33 EDT
(In reply to comment #2)
> Well, libpng12-devel's requires contain an explicit "%{epoch}" 

Indeed, and is it not a yum bug that it fails to expand that as "0"?  rpm doesn't complain about it.
Comment 4 Ralf Corsepius 2012-08-22 01:45:54 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > Well, libpng12-devel's requires contain an explicit "%{epoch}" 
> 
> Indeed, and is it not a yum bug that it fails to expand that as "0"?  rpm
> doesn't complain about it.

Well, yum is the last component, I'd blame. If at all, I see reasons to blame yum for the misleading error message it issues.

... I'd blame rpmbuild, rpmlint, AutoQA, createrepo (the package reviewer) ... all could have seen this issue ;)
Comment 5 Jan Zeleny 2012-08-22 03:25:09 EDT
If any component, rpmbuild would be the one to blame. But it's really questionable because rpmbuild doesn't know packager's intentions when trying to expand macros. So strictly speaking, the behaviour is correct.

The problem is that you don't have Epoch defined in the spec file. I just did a brief test on my machine and defining the Epoch solved the issue.
Comment 6 Ralf Corsepius 2012-08-22 05:23:26 EDT
(In reply to comment #5)
> If any component, rpmbuild would be the one to blame.

Depends on what to blame whom for :)

* rpm would be to blame for for not having aborted on an unexpanded %{} pattern in Requires ...

* Rpmlint would be to blame for not caught this unexpanded %{epoch} and for being entirely confused:

# rpmlint results_libpng12/1.2.50/1.fc19/libpng12-devel-1.2.50-1.fc19.x86_64.rpm 
libpng12-devel.x86_64: W: spelling-error Summary(en_US) libpng -> sibling
libpng12-devel.x86_64: E: rpath-in-buildconfig /usr/bin/libpng12-config lines ['43']
libpng12-devel.x86_64: W: no-manual-page-for-binary libpng-config
libpng12-devel.x86_64: W: no-manual-page-for-binary libpng12-config
1 packages and 0 specfiles checked; 1 errors, 3 warnings.

* Similar for AutoQA: AutoQA should now that %{} patterns in Requires/Provides are never correct.

...
Comment 7 Tom Lane 2012-08-22 09:41:24 EDT
(In reply to comment #6) 
> * rpm would be to blame for for not having aborted on an unexpanded %{}
> pattern in Requires ...

I guess the question is, why is it unexpanded?  At some level rpm has certainly got the concept that Epoch defaults to zero.  I don't understand why that doesn't seem to include expanding %{epoch} to "0" when there's no explicit Epoch: line.

Anyway, the path of least resistance for the moment is to remove the unnecessary %{epoch} usage from the libpng12 specfile.  But it sure seems like something should have complained earlier, if this isn't a supported usage.
Comment 8 Susi Lehtola 2012-08-22 17:50:22 EDT
(In reply to comment #7)
> I guess the question is, why is it unexpanded?  At some level rpm has
> certainly got the concept that Epoch defaults to zero.  I don't understand
> why that doesn't seem to include expanding %{epoch} to "0" when there's no
> explicit Epoch: line.

Yes, I'd regard this as a bug in RPM. Time to open a bug?
Comment 9 Fedora Update System 2012-08-22 19:05:14 EDT
libpng12-1.2.50-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/libpng12-1.2.50-2.fc18
Comment 10 Tom Lane 2012-08-22 22:47:04 EDT
Well, in any case it seems like this is not yum's problem in particular, so I'll reassign the bug back to libpng12.  I've already pushed an update to remove the unnecessary %{epoch} reference from it.

It does seem to me that rpm and/or rpmlint could be more helpful here, but I'll leave it to the relevant experts whether to open new bugs against those tools.
Comment 11 Fedora Update System 2012-09-17 19:01:59 EDT
libpng12-1.2.50-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Admin XMLRPC Client 2013-05-14 09:53:32 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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