Bug 850628
Summary: | dependency/NEVR issues | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ralf Corsepius <rc040203> |
Component: | libpng12 | Assignee: | Petr Hracek <phracek> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | ffesti, gholms, hhorak, jzeleny, maxamillion, packaging-team, rdieter, susi.lehtola, tim.lauridsen, zpavlas |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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 20:05:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ralf Corsepius
2012-08-22 03:23:06 UTC
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. |