[Fedora-packaging] Question about how libgcj-devel requires zlib

[Panu Matilainen]

On Tue, 23 Sep 2008, Ralf Corsepius wrote:

> On Tue, 2008-09-23 at 09:49 +0300, Panu Matilainen wrote:
>> On Tue, 23 Sep 2008, Ralf Corsepius wrote:
>>
>>> On Tue, 2008-09-23 at 09:18 +0300, Panu Matilainen wrote:
>>>> The new rpm in rawhide adds ISA provides (ie the (x86-32) stuff")
>>>> automatically for all non-noarch packages (including subpackages), all
>>>> that's needed is rebuild. So every package rebuilt since rpm 4.5.90.x
>>>> landed in rawhide already has them.
>>>>
>>>> The main use-cases for this feature are:
>>>> a) -devel package dependencies on other -devel packages
>>>> b) BuildRequires
>>>> c) manual dependencies for plugins and such
>>> Which kinds of problems does this solve?
>>
>> If it wasn't obvious from the list above...
>> a) foo-devel requires bar-devel. Currently bar-devel.i386 is sufficient to
>> satisfy foo-devel.x86_64 which is obviously not correct.
> bug in rpm's version comparison => Your addition doesn't solve it.

No. There hasn't been a way to specify dependency on certain architecture, 
rpm has no way of knowing if "foo" in "Requires: foo" is supposed to be 
same arch or not.

Sure it would be possible to teach rpm to grok the name.arch syntax for 
(build)requires too, but it would require changing every depsolver to 
understand it too, and *that* would be incompatible change in spec syntax 
as well. Whereas the new provide introduces precisely zero 
incompatibilities.

>> b) Similarly to a), BuildRequires: foo-devel. Currently, if you have
>> foo-devel.i386 installed and try to build for x86_64, it's considered
>> satisfied which is obviously not correct.
> same as above.

Same as above.

>
>> c) A package depends on a dlopen()'ed plugin, say "foo-plugin". The plugin
>> needs to be of compatible arch to work, quite obviously. The only way to
>> express this correctly right now is to use file dependencies on
>> %{_libdir}/something.
> Correct. You don't solve anything that file-deps would not solve.
>
>>> So far I don't see any. Conversely, AFAIU all this does, is to add more
>>> incompatibilities, more rpmdb entries, all for information which already
>>> is hidden somewhere else.
>>
>> So you'd rather change all -devel and build dependencies to
>> %{_libdir}/libfoo.so file dependencies?
> Correct. I think, all what these rpm meta-tag do is to add pollution to
> the rpmdb, to solve a problem to which file-deps would be an already
> existing "natural solution", because they actually are file deps at
> run-time.

Except there isn't always an "arch-specific" file you can depend on. Often 
there is, but not always. File-dependencies are more expensive to 
look up than regular provides.

If file dependencies on things like 
/usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.3.2.v3349.jar 
are so wonderfully perfect solution to the problem at hand, I wonder why 
people aren't using them for everything then.

 	- Panu -