3905 2013-02-18 16:30:29 +0000 ipkg/opkg data does not track dependency on version numbers 2013-03-01 13:41:28 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified All Multiple RESOLVED WORKSFORME Medium major 1.4 1 alexandru.damian richard.purdie poky.bs.watcher poky.watcher sgw --- --- --- oldest_to_newest 29926 0 alexandru.damian 2013-02-18 16:30:29 +0000 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. 29928 1 alexandru.damian 2013-02-18 16:35:30 +0000 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)" 29959 2 richard.purdie 2013-02-19 13:30:38 +0000 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? 30327 3 richard.purdie 2013-03-01 13:41:28 +0000 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.