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

[Ralf Corsepius]

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.

> 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.

> 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.

>  And there's no incompatibility 
> here, specs remain backwards compatible as long as you use the conditional 
> %{?_isa} construct for this.
More pollution to rpmdb, more sources of errors and conflicts.

Ralf