[opensuse-packaging] How to flexibly express "Requires" dependency to have same version as "BuildRequires"
Hi. Is there any convenient way to force package depend (at runtime) on libfoo version X, where X is the version of libfoo-devel, that was used when package was built? Is it possible to do so, without explicitly specifying version (X) itself in the spec file? So that upgrading libfoo to version X+1 in the same project won't break this package, and just trigger package rebuild with new dependencies on X+1. The problem arises in package Ardour, which detects liblilv version on compile time and uses new api if available. This forces package to have same version of run-time "Requires" dependency as "BuildRequires". -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 2015-11-17 20:20, Roman Evstifeev wrote:
Hi. Is there any convenient way to force package depend (at runtime) on libfoo version X, where X is the version of libfoo-devel, that was used when package was built?
%requires_eq libfoo-devel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thanks. Is the line you wrote correct? I am seeing this macro used as this:
BuildRequires: libqt4-devel >= 4.8.0
%requires_eq libqt4
On Wed, Nov 18, 2015 at 1:43 AM, Jan Engelhardt
On Tuesday 2015-11-17 20:20, Roman Evstifeev wrote:
Hi. Is there any convenient way to force package depend (at runtime) on libfoo version X, where X is the version of libfoo-devel, that was used when package was built?
%requires_eq libfoo-devel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
18.11.2015 01:43, Jan Engelhardt пишет:
On Tuesday 2015-11-17 20:20, Roman Evstifeev wrote:
Hi. Is there any convenient way to force package depend (at runtime) on libfoo version X, where X is the version of libfoo-devel, that was used when package was built?
%requires_eq libfoo-devel
Where this macro is defined? rpm --eval does not show it here (on TW)? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2015-11-18 04:40, Andrei Borzenkov wrote:
18.11.2015 01:43, Jan Engelhardt пишет:
On Tuesday 2015-11-17 20:20, Roman Evstifeev wrote:
Hi. Is there any convenient way to force package depend (at runtime) on libfoo version X, where X is the version of libfoo-devel, that was used when package was built?
%requires_eq libfoo-devel
Where this macro is defined? rpm --eval does not show it here (on TW)?
To see macro definitions, you must use `rpm --showrc`, not `rpm --eval`. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2015-11-18 04:40, Andrei Borzenkov wrote:
18.11.2015 01:43, Jan Engelhardt пишет:
On Tuesday 2015-11-17 20:20, Roman Evstifeev wrote:
Hi. Is there any convenient way to force package depend (at runtime) on libfoo version X, where X is the version of libfoo-devel, that was used when package was built?
%requires_eq libfoo-devel
Where this macro is defined? rpm --eval does not show it here (on TW)?
To see macro definitions, you must use `rpm --showrc`, not `rpm --eval`. -- This problem of explicit runtime requires intrigues me, rpm uses ldd to find the requires and I can understand the problem with binaries
On 11/18/15, Jan Engelhardt
On Thu, Nov 19, 2015 at 10:18 AM, Dave Plater
This problem of explicit runtime requires intrigues me, rpm uses ldd to find the requires and I can understand the problem with binaries that are executed via shell commands but often libraries that are clearly linked at build time aren't picked up by ldd.
If library is present on command line but is not actually referenced it probably won't be listed in resulting binary as well. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 17.11.2015 um 20:20 schrieb Roman Evstifeev:
Hi. Is there any convenient way to force package depend (at runtime) on libfoo version X, where X is the version of libfoo-devel, that was used when package was built? Is it possible to do so, without explicitly specifying version (X) itself in the spec file? So that upgrading libfoo to version X+1 in the same project won't break this package, and just trigger package rebuild with new dependencies on X+1.
rpm does not provide such info. All it provides is dependencies based on the SONAME (and related info). The same bug exists for packman, some packages have now a hack to require a specific version. Ideally rpm dependencies should also cover the repo info where a "Provides" comes from, and the Requires of the other package should use that. This is partly handled by libzypp "vendor" handling. But in the end its not good enough if the given "Provides" is already installed. Not sure if that must be fixed at libzypp or rpm level. I guess libzypp should be more strict with provides/requires. If a pkgA from repo X requires "something", and another pkgB from X provides that "something" and that pkgB is newer than the already installed "something" then libzypp should prefer pkgB from X. Example: taglib has the same SONAME since a long time, but for whatever reason upstreams keeps adding features to that SONAME, instead of just changing it. As a result, if a pkg is built against a newer version of taglib, packages have runtime failures. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Olaf Hering
Example: taglib has the same SONAME since a long time, but for whatever reason upstreams keeps adding features to that SONAME, instead of just changing it. As a result, if a pkg is built against a newer version of taglib, packages have runtime failures.
That can be solved by proper use of symbol versions. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Andreas Schwab (schwab@suse.de) [20151118 10:15]:
That can be solved by proper use of symbol versions.
Seeing how seldom they are used they seem to be something most developers avoid… Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday 2015-11-24 13:42, Philipp Thomas wrote:
* Andreas Schwab (schwab@suse.de) [20151118 10:15]:
That can be solved by proper use of symbol versions.
Seeing how seldom they are used they seem to be something most developers avoid…
Well, those who do not want to do symbol versions can (and rightfully so) get away with SO bumping. More interesting is the case when e.g. a cornercase bugfix is applied which does not affect the ABI, nor the API, and downstream sort of relies on the fixed variant nevertheless. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Jan Engelhardt (jengelh@inai.de) [20151124 16:21]:
Well, those who do not want to do symbol versions can (and rightfully so) get away with SO bumping.
Of cause they can but using symbol versions is by far the better way to handle it. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Tue, 24 Nov 2015, Jan Engelhardt wrote:
Seeing how seldom they are used they seem to be something most developers avoid…
Well, those who do not want to do symbol versions can (and rightfully so) get away with SO bumping.
More interesting is the case when e.g. a cornercase bugfix is applied which does not affect the ABI, nor the API, and downstream sort of relies on the fixed variant nevertheless.
A bugfix that's observable (and only those can be relied on from external downstreams) is an API change as well, in the strictest sense, and hence should result in a new sym-version or an SO bump (and which point then this can be trivially dependend on). Of course, that's all in an ideal world, in reality most developers don't know much about how to write proper shared libraries. Ciao, Michael.
participants (8)
-
Andreas Schwab -
Andrei Borzenkov -
Dave Plater -
Jan Engelhardt -
Michael Matz -
Olaf Hering -
Philipp Thomas -
Roman Evstifeev