Isn't it enough to set RPROVIDES/RCONFLICTS/RREPLACES combo to say that eudev really replaces old udev even when the package version is lower.
This used to fix such upgrade-path issues before, but I've stopped testing them long time ago. On Wed, May 17, 2017 at 5:26 PM, Bryan Evenson <[email protected]> wrote: > All, > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf > > Of Bryan Evenson > > Sent: Tuesday, May 16, 2017 2:01 PM > > To: [email protected] > > Subject: [OE-core] eudev: opkg not automatically upgrading from udev to > > eudev > > > > > > I have an image based on core-image-minimal that uses sysvinit for init > and > > opkg for package management. I am doing some upgrade testing and I see > > an issue with eudev. I am testing upgrading an image that was built > under > > dizzy to my latest image built under morty. I'm first testing that all > the correct > > packages and new dependencies are correctly being identified for upgrade > > by running "opkg update; opkg upgrade --download-only" from the > > command line and comparing what is in the opkg cache directory with what > > was available. All packages except eudev and udev-cache are being > > downloaded for upgrade. > > > > I ran the opkg upgrade again with the -V4 option for additional debug > output > > Here's what I saw in one section regarding udev: > > > > pkg_hash_fetch_best_installation_candidate: Best installation candidate > for > > udev: > > pkg_hash_fetch_best_installation_candidate: apkg=udev nprovides=2. > > pkg_hash_fetch_best_installation_candidate: Adding eudev to providers. > > pkg_hash_fetch_best_installation_candidate: Adding udev to providers. > > pkg_hash_fetch_best_installation_candidate: eudev arch=armv5e > > arch_priority=41 version=3.2. > > pkg_hash_fetch_best_installation_candidate: udev arch=arm926ejste > > arch_priority=51 version=182. > > pkg_hash_fetch_best_installation_candidate: Candidate: udev 182. > > pkg_hash_fetch_best_installation_candidate: 2 matching pkgs for > > apkg=udev: > > pkg_hash_fetch_best_installation_candidate: eudev 3.2 armv5e > > pkg_hash_fetch_best_installation_candidate: udev 182 arm926ejste > > opkg_upgrade_pkg: Comparing visible versions of pkg udev: > > 182-r9.9 is installed > > 182-r9.9 is available > > 0 was comparison result > > opkg_upgrade_pkg: Package udev (182-r9.9) installed in root is up to > date. > > > > I'm assuming the problem is that udev is version 182 and eudev is > version 3.2 > > and that opkg doesn't think udev needs to be upgraded. Is there an > > RDEPENDS that needs to be added somewhere so opkg sees that it needs to > > upgrade udev to eudev? > > I made some changes and now both eudev and udev-cache are being pulled in > on upgrade. However, I'd like a second opinion that what I did was > reasonable. > > First, I created eudev_%.bbappend in my private layer and added "PE = "1"" > to the bbappend. Since the numbering scheme changed between udev and > eudev, I figured this was a reasonable move. This brought the update > udev-cache in for upgrade, but not eudev. In my private layer, I also have > an image version number package. I added eudev to the RDEPENDS list for > this package since my image, which now has linux version 4.4, does depend > on eudev. > > Does this sound reasonable? Is there a better way to do the same thing? > > Thanks, > Bryan > > > > > Thanks, > > Bryan > > -- > > _______________________________________________ > > Openembedded-core mailing list > > [email protected] > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
