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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
