This is actually a subcase of #446, closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1344#issuecomment-1718921839
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1344 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1344#event-10368445792
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
> Should this work for different-arch builders as well?
This seems to be different problem. Apparently there was soname bump in matio
package on Sept 17. It seems that vips woudl deserve rebuilt
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Well, it's only a binding, not having anything compiled.
Should this work for different-arch builders as well?
```
DEBUG util.py:621: Error:
DEBUG util.py:621: Problem: package ruby-libs-2.7.1-134.fc33.s390x requires
libffi.so.6()(64bit), but none of the providers can be installed
DEBUG
Le mer. 26 août 2020 à 15:00, Vít Ondruch a
écrit :
> It would be nice if we had install time alternative to %{?_isa}. That
> would help to pull in the right arch package from noarch package.
>
> My use case is to have rubygem-ruby-vips, where this is noarch package is
> using libffi to load
BTW systemd is using [nice
trick](https://github.com/systemd/systemd/blob/0c94a31464384324a7394d57abbc9fbafa189a75/src/core/macros.systemd.in#L47)
to check number of parameters macro has. Is there something like this
available in RPM?
--
You are receiving this because you are subscribed to
So would be macro like this acceptable for upstream RPM?
~~~
# %%Requires - Require library with right bitness.
#
# Usage: %%Requires [options]
#
# There is no way to know the installation architecture of noarch package
# during buildtime. Therefore this macro allows to require the specified
#
Rpm's API/ABI is not particularly stable, so it's not the best candidate.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> libc.so.6 is used here as an example because it's an unmoving target, but
> whether that's the best choice depends on the case.
And how about librpm.so.9?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
These kind of "indirect" arch dependencies from noarch packages are indeed an
old problem.
This is not an actual solution, but with rich dependencies, there's at least a
chance to express something like that:
```
Requires: (libvips.so.42()(64bit) if libc.so.6()(64bit))
Requires:
> Requires: "libvips.so.42%%{?_isa}
This specific example would not work, because the actual provide is
`libvips.so.42()(64bit)`, which makes me wonder why there is the first pair of
parentheses But anyway, I would find a way :)
--
You are receiving this because you are subscribed to
It would be probably enough, if the requires were processed and expanded during
installation, so I would need just:
~~~
Requires: "libvips.so.42%%{?_isa}
~~~
i.e. escape the macro.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
It would be nice if we had install time alternative to `%{?_isa}`. That would
help to pull in the right arch package from noarch package.
My use case is to have rubygem-ruby-vips, where this is noarch package is using
libffi to load libraries, to `Requires: "libvips.so.42%{?_isa}", where this
13 matches
Mail list logo
