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
The message says to file this against yum, and indeed I do not believe there is anything wrong with libpng12's dependency declarations.
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.
(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.
(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 ;)
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.
(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. ...
(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.
(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?
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
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.
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.