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

[Bryan Evenson]

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:martin.jansa at gmail.com]
Sent: Wednesday, May 17, 2017 12:18 PM
To: Bryan Evenson <bevenson at melinkcorp.com>
Cc: Openembedded-core at lists.openembedded.org
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 <bevenson at melinkcorp.com<mailto:bevenson at melinkcorp.com>> wrote:
All,

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org<mailto:openembedded-core-bounces at lists.openembedded.org>
> [mailto: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<mailto: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?

Thanks,
Bryan

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170517/7762572e/attachment-0002.html>