Bug 3905 - ipkg/opkg data does not track dependency on version numbers
Summary: ipkg/opkg data does not track dependency on version numbers
Status: RESOLVED WORKSFORME
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: unspecified
Hardware: All Multiple
: Medium major
Target Milestone: 1.4
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-02-18 16:30 UTC by Alexandru Damian
Modified: 2013-03-01 13:41 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.