Re: Question about how libgcj-devel requires zlib

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux