On Mon, 23 Feb 2009, Orcan Ogetbil wrote:
On Mon, Feb 23, 2009 at 7:29 AM, Panu Matilainen wrote:
On Sun, 22 Feb 2009, Orcan Ogetbil wrote:
On Fri, Feb 20, 2009 at 3:06 AM, Panu Matilainen wrote:
On Thu, 19 Feb 2009, Jochen Schmitt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Orcan Ogetbil schrieb:
+%ifarch x86_64 ppc64
+Provides:
%{_libdir}/gcj/%{name}/%{name}-%{version}.jar.so()(64bit)
+%else
+Provides: %{_libdir}/gcj/%{name}/%{name}-%{version}.jar.so
+%endif
%description
iText is a library that allows you to generate
@@ -141,6 +147,9 @@
#
-----------------------------------------------------------------------------
- From my point of view, this is a workaround, which is only good until
rpmbuild may be fixed.
Fix what? What exactly is being worked around here?
- Panu -
This is an issue with the rpmbuild's automatic dependency generation.
Here's the story:
itext provides (rpm -q --provides itext):
itext-2.1.4.jar.so()(64bit)
which is in the directory /usr/lib64/gcj/itext/ . Note that this is
not a standard library path.
Meanwhile, pdftk requires (rpm -qR pdftk):
/usr/lib64/gcj/itext/itext-2.1.4.jar.so()(64bit)
Notice the full path, which was not in the Provides of itext. Because
of this path, the pdftk RPM won't install, complaining about unmet
dependencies.
Well sure that requires looks pretty screwed, something that rpm should not
ever generate.
Why does it look screwed? Why are full paths on Requires/Provides "bad"?
Nothing wrong with file dependencies, but the above is not a file:
[pmatilai@turre ~]$ repoquery -l itext|grep jar\\.so
/usr/lib64/gcj/itext/itext-2.1.4.jar.so
[pmatilai@turre ~]$ repoquery --provides itext|grep jar\\.so
itext-2.1.4.jar.so()(64bit)
Therefore we put an additional Provides:
/usr/lib64/gcj/itext/itext-2.1.4.jar.so()(64bit) on itext.
I dont see pdftk in Fedora, other that it has been there and is now marked
dead.package. What pdftk package are we talking about here?
Sorry, I should have given this link:
https://bugzilla.redhat.com/show_bug.cgi?id=485641
Is there a better solution?
Fix the busted requires instead?
- Panu -
Yes, that was the other option (not sure why you call it "busted"
though). I asked a few people and the common advice is to not lie to
RPM. If it asks a full path, give it a full path.
Again, file requires are fine but this is not a file:
/usr/lib64/gcj/itext/itext-2.1.4.jar.so()(64bit)
The dependency should either be: "itext-2.1.4.jar.so()(64bit)" or then for
the actual file: "/usr/lib64/gcj/itext/itext-2.1.4.jar.so". Both of these
are provided by itext already.
So what will be the benefit of hacking the Requires of pdftk?
The question really is, where the heck does the strange
path-and-soname-mixed-up require come from in the first place? I dont see
anything like that in the spec so it suggests a bug in whatever it is that
generates the dependency - rpm's "javadeps" extractor maybe. The pdftk
src.rpm doesn't want to build in mock here so I'm having trouble
reproducing it.
Hmm.. there's at least one somewhat similar (in that it's java-related)
very very buggy dependency, although provide in this case:
[pmatilai@turre ~]$ repoquery --provides jna|grep libjni
/builddir/build/BUILD/jna-3.0.4-svn729/build-d64/native/libjnidispatch.so()(64bit)
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
