Re: Question about how libgcj-devel requires zlib

Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx> · Tue, 23 Sep 2008 12:54:58 +0300 (EEST)

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 -

--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging