rpms/itext/devel itext.spec,1.13,1.14

[Panu Matilainen]

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 at turre ~]$ repoquery -l itext|grep jar\\.so
/usr/lib64/gcj/itext/itext-2.1.4.jar.so
[pmatilai at 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 at turre ~]$ repoquery --provides jna|grep libjni
/builddir/build/BUILD/jna-3.0.4-svn729/build-d64/native/libjnidispatch.so()(64bit)

 	- Panu -