Martin, Thanks for the pointers. I think I finally have it working correctly. I added RPROVIDES/RCONFLICTS/RREPLACES in my eudev bbappend to state it replaces udev. I also needed to set PE = 1 for udev-cache. Since udev-cache didn’t change the package name, I can’t say it RCONFLICTS/RREPLACES itself.
Thanks, Bryan From: Martin Jansa [mailto:[email protected]] Sent: Wednesday, May 17, 2017 12:18 PM To: Bryan Evenson <[email protected]> Cc: [email protected] Subject: Re: [OE-core] eudev: opkg not automatically upgrading from udev to eudev 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]<mailto:[email protected]>> wrote: All, > -----Original Message----- > From: > [email protected]<mailto:[email protected]> > [mailto:[email protected]<mailto:[email protected]>] > On Behalf > Of Bryan Evenson > Sent: Tuesday, May 16, 2017 2:01 PM > To: > [email protected]<mailto:[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]<mailto:[email protected]> > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list [email protected]<mailto:[email protected]> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
