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

[Ralf Corsepius]

On Tue, 2008-09-23 at 12:54 +0300, Panu Matilainen wrote:
> 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, 
Exactly: This is the BUG in *RPM*.


> rpm has no way of knowing if "foo" in "Requires: foo" is supposed to be 
> same arch or not.
Right, but it could (and should have done so for ages) The information
is present.

> 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,
Correct, that's another bug. The depsolver should be part of RPM.

> >> 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.
And where is the problem? 

A "client" package which depends on some "provider" almost always
depends on the provider to provide a file,
no matter what this file actually is.

I.e. you hardly ever need the "architecture", you almost always need the
file and nothing else.

>  Often 
> there is, but not always. File-dependencies are more expensive to 
> look up than regular provides.
Wrong. Inside of rpm everything is database lookups. Whether these are
file-deps or artificial provides doesn't matter. Whether rpm/yum etc.
handle them efficiently, is a different matter.

> 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.
Lack of insight, people being subject to FUD/propaganda for years?
People being confused by the very few corner cases (SONAMES)?


Ralf