Bug 3905

Summary: ipkg/opkg data does not track dependency on version numbers
Product: [Build System, Metadata & Runtime] BitBake Reporter: Alexandru Damian <alexandru.damian>
Component: bitbakeAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED WORKSFORME QA Contact:
Severity: major    
Priority: Medium CC: poky.bs.watcher, poky.watcher, sgw
Version: unspecified   
Target Milestone: 1.4   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Alexandru Damian 2013-02-18 16:30:29 UTC
When using ipkg/opkg package system,

all version-specific DEPENDS, CONFLICTS, RDEPENDS and RCONFLICTS 

will fail to take into account the specific version number dependency, probably through a limitation of opkg/ipkg.

e.g., when init-ifupdown_1.0 recipe declares 
RCONFLICTS_${PN} = "netbase (< 1:5.0)"

it is trying to forbid all netbase packages version earlier than 5.0.

However, the opkg/ipkg package management will refuse to install both init-ifupdown and netbase-5.0 ! on the account that the conflict list for init-ifupdown  contains "netbase", without any reference to the version number.


This needs to be contained/fixed/documented.
Comment 1 Alexandru Damian 2013-02-18 16:35:30 UTC
only 4 instances in the base layers as of today.

# grep -rIn "[A-Z]\+.*=.*(.*[0-9]\+\.[0-9]\+)" meta*

meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb:37:RCONFLICTS_${PN} = "netbase (< 1:5.0)"
meta/recipes-support/libcheck/libcheck_0.9.9.bb:23:RREPLACES_${PN} = "check (<= 0.9.5)"
meta/recipes-support/gnutls/gnutls.inc:4:DEPENDS = "zlib lzo libtasn1 libgcrypt (>= 1.4.2) libcap readline"
meta/recipes-support/libusb/libusb1_1.0.9.bb:1:DESCRIPTION = "Userspace library to access USB (version 1.0)"
Comment 2 Richard Purdie 2013-02-19 13:30:38 UTC
Previously, we found the version component of the field was getting lost in some cases due to: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=10f05d5b5866317a8c2de09455b548ff848afecd

It sounds like something else is losing the version part of the field, or you have stale packages in the system somehow, (likely a machine specific package becoming non-machine specific as I know Martin has reported some issues in this area).

Can you reproduce this on a clean build?
Comment 3 Richard Purdie 2013-03-01 13:41:28 UTC
I don't have enough information to be able to reproduce this, going to assume it was fixed by the patch mentioned, or caused by the machine specific package transition as indicated.