All,
> -----Original Message-----
> From: Bryan Evenson
> Sent: Wednesday, May 17, 2017 11:27 AM
> To: Bryan Evenson <beven...@melinkcorp.com>; Openembedded-
> c...@lists.openembedded.org
> Subject: RE: eudev: opkg not automatically upgrading from udev to eudev
>
> All,
>
> > -----Original Message-----
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf Of
> > Bryan Evenson
> > Sent: Tuesday, May 16, 2017 2:01 PM
> > To: Openembedded-core@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@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
