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