For runtime dependencies added automatically via shlibdeps, Yocto often adds an additional '(>= <current-version-of-dependency>)' restriction to the generated RDEPENDS. It would be nice to document this, as it means the behavior differs between automatically added runtime dependencies and dependencies added manually to RDEPENDS. The implementation is in package_do_shlibs() in meta/classes/package.bbclass by the way. The code that adds the version requirement is near 'if ver_needed:'.
I am adding Paul Eggleton to this bug and would like some explanation on the code in package.bbclass. Here is a link to that class: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass. The code is around line 1685. Thanks, Scott
I think we can simply add an additional sentence under the glossary entry for RDEPENDS (not that that isn't already huge, but we don't really have a better place right now). Additionally, I've just noticed that we talk about shlibdeps being from shared libraries on others, but that's not quite accurate, and we should be specific in that it's package names being added to RDEPENDS. Here's what I would suggest as an extended rewording to cover all of that: --------- snip --------- shlibdeps: If a runtime package contains a compiled binary, the build processes the binary in order to determine any shared libraries (.so files) to which it is dynamically linked. The build process adds the packages containing these libraries to RDEPENDS when creating the runtime package. In addition, if the shared library is versioned, the dependency will have the version appended to it in order to force an upgrade to the appropriate version if needed. --------- snip ---------
Looks good, but this part seems a bit vague to me: > In addition, if the shared library is versioned, the dependency will have the > version appended to it in order to force an upgrade to the appropriate > version if needed. I'd clarify it to answer the following questions: - What does it mean for the library to be versioned? Is it a restriction on the recipe that installs the library? Perhaps the description could be written more concretely and in a way that avoids the word "versioned". - What does it mean to "have the version appended"? Have it appended to what? What kind of restrictions on the version are we talking about? What are we forcing an upgrade of, and under what circumstances?
Good points on the verbiage. If you could provide further explanation on those two points Paul I could create that update in the glossary. Thanks, Scott
The way I read the code, if the library uses the standard library versioning scheme then that is enough to trigger the behaviour we are describing. What are we forcing an upgrade of? Surely the library package in question - is there another interpretation? As to when this gets applied, I suspect it's going to depend on which package manager you are using. Broadly it's going to mean what you would expect it to mean: if you attempt to install this package then you need the stated dependencies including any version specifiers to be satisfied, so the package manager will do what's needed to satisfy them with the available packages, or fail if it can't. That seems to me like too much detail for this section though. Ulf, I have to ask - does all of this seem like unexpected behaviour to you? I can provide an alternate wording, I'd just like to understand what you want to cover.
(In reply to comment #5) > The way I read the code, if the library uses the standard library versioning > scheme then that is enough to trigger the behaviour we are describing. That still could be more concrete. The restriction is on the version of the package. How is the version of the library mapped to that, provided it uses the "standard library versioning scheme"? "Standard library versioning scheme" could also be put a bit more concretely. I'd mention stuff like filenames, sonames, etc. - whatever might be relevant here. I don't think it would have to be a very long description still. I'd write it myself if I knew the details. > What are we forcing an upgrade of? Surely the library package in question - > is there another interpretation? Yes, the interpretation of confusion. ;) Instead of talking about appending things to dependencies, I'd say that the automatically added RDEPENDS is on the form "foo (>= <current version of foo>)". It seems unnecessarily vague to "append" something to a dependency, and it's not clear that it's a >= type of restriction. I'd then add something like "the point of restricting the dependency's version is to force an upgrade of installed older versions of it, under the assumption that the older version might be incompatible". > Ulf, I have to ask - does all of this seem like unexpected behaviour to you? > I can provide an alternate wording, I'd just like to understand what you > want to cover. Yes, it was surprising to me. If automatically added RDEPENDS also get automatically added version restrictions, I would have expected it to be documented.
Hi, I am moving this bug to the next release (2.2). With the final push for docs I will not be able to get to it for 2.1 Scott
Hi, I put in Paul's first suggested correction for "shlibdeps" (see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-RDEPENDS). The back-and-forth stuff in the comments here didn't seem to be resolved to the point where other wording might be applied. I don't understand the content here so... Is there further definition for this fix? Thanks, Scott
Merged in yocto-docs d94de0b24591206620c83a9022a9d813141a7637.
Ross, Setting the doc flag to "done" since the bug was put into RESOLVED state. Scott