[OE-core] eudev: opkg not automatically upgrading from udev to eudev

[Bryan Evenson]

All,

> -----Original Message-----
> From: Bryan Evenson
> Sent: Wednesday, May 17, 2017 11:27 AM
> To: Bryan Evenson <bevenson at melinkcorp.com>; Openembedded-
> core at lists.openembedded.org
> Subject: RE: eudev: opkg not automatically upgrading from udev to eudev
> 
> All,
> 
> > -----Original Message-----
> > From: openembedded-core-bounces at lists.openembedded.org
> > [mailto:openembedded-core-bounces at lists.openembedded.org] On
> Behalf Of
> > Bryan Evenson
> > Sent: Tuesday, May 16, 2017 2:01 PM
> > To: Openembedded-core at lists.openembedded.org
> > 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?

Things didn't go as well when I did the upgrade.  I attempted the upgrade with "opkg upgrade" (no options) and everything worked until then end.  Then I got a bunch of error messages like the following:

* check_data_file_clashes: Package eudev wants to install file /lib/udev/scsi_id
        But that file is already provided by package  * udev

After the upgrade neither udev nor eudev were installed on my system.  I've solved similar problems in the past by adding RCONFLICTS/RREPLACES listings in the new packages recipe, but since eudev is listed as providing udev I'm not sure what is appropriate here.  Should there be RCONFLICTS/RREPLACES in the eudev recipe, or is there another solution to this problem?

Thanks,
Bryan

> 
> Thanks,
> Bryan
> 
> >
> > Thanks,
> > Bryan
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core