Yes, that sounds reasonable, just keep in mind that PE bumps are forever (once you introduce it in your binary feed, you probably wont be able to ever remove the .bbappend with it), unless you get the PE bump merged in oe-core as well.

I think you should just submit the fix to oe-core and then your .bbappend will be only temporary until you upgrade to the release which already includes the fix.

On Wed, May 17, 2017 at 7:24 PM, Bryan Evenson <bevenson@melinkcorp.com> wrote:

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@gmail.com]
Sent: Wednesday, May 17, 2017 12:18 PM
To: Bryan Evenson <bevenson@melinkcorp.com>
Cc: Openembedded-core@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@melinkcorp.com> wrote:

All,


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

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