> The whole point of sonames is that it's NOT tied to versions but the soname
> abstraction, and this kind of dependency breaks that point.
I think "the point" is that binaries should not need to re-link when a shared
object is updated with a backward-compatible version.
However, because rpm cu
> Oh, one more caveat: if the shared library uses symbol versioning, exclude it
> from the new generator.
Understood. This mock-up only applies the externally-enhanced version info to
shared objects that don't provide versioned symbols, and any future work would
do the same.
--
Reply to this
> add a versioned requires. (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >=
> 4.8.0).
The whole point of sonames is that it's NOT tied to a particular version, and
this kind of dependency breaks that point.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwar
Oh, one more caveat: if the shared library uses symbol versioning, exclude it
from the new generator.
This is important because of at least one important package: `glibc`. Without
this, every build would depend on the latest version of `glibc`. `glibc` spends
a lot of effort making sure that thi
Looking at the contents of /usr/lib64 on my local system, I see some cases that
look like developers not versioning their so _at all_ (e.g.
libasprintf.so.0.0.0, and 144 others). But that's about 7% of all shared
object files.
Generally: that sounds like it'd be a major improvement, with cover
A different approach, which wouldn't require calling into `rpm` and dealing
with multiple rpms, would be to:
1. change the existing Provides generator for SONAME to use a version:
`libcurl.so.4()(64bit)` → `libcurl.so.4()(64bit) = 4.8.0`. I think this would
be backwards compatible: because the P
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with %s)
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with %s)
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with %s)
@gordonmessmer pushed 1 commit.
c54b9218b9b0aafb643eaa5afdaf490ffb6c1107 Review fixes.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/369bf9b91e5e85f00f7a925e152137598fbed1ba..c54b9218b9b0aafb643eaa5afdaf490ffb6c1107
You are receiving this because you are s
> calling rpm from within a generator has always been considered a bad thing to
> do
Understood. I don't think this PR is the _right_ way to solve this problem.
It's just a quick mock-up; I expect to throw it away and do something "the
right way" later.
My hope is that we can discuss whether
@keszybz commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with %s)\n" "$
I just want to mention that:
- calling `rpm` from within a generator has always been considered a bad thing
to do
- `rpm -q --whatprovides` may return multiple things -- it might be safer to
`rpm -qf` the actual .so file
--
Reply to this email directly or view it on GitHub:
https://github.co
@gordonmessmer pushed 1 commit.
369bf9b91e5e85f00f7a925e152137598fbed1ba Enhance requires with version
information from the build root.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/231eb85c849df1c66146638349403757f7ed540c..369bf9b91e5e85f00f7a925e1521375
For shared objects without versioned symbols, this additional information
allows rpm to track minor-version dependencies.
The initial version of this PR updates the external dependency generator, so it
will only affect packages that set `%global _use_internal_dependency_generator
0`, so it's mo
Found another problematic case:
https://code.opensuse.org/package/ocaml-rpm-macros/blob/819e56/f/ocaml-rpm-macros.spec#_464
`'%%{?_smp_mflags}'`
becomes
`'-j${RPM_BUILD_NCPUS}'` and the variable does not get expanded now, causing a
compilation failure. I guess, using double-quotes should fix it.
16 matches
Mail list logo
