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

[Martin Jansa]

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>
wrote:

> 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?
>
> Thanks,
> Bryan
>
> >
> > Thanks,
> > Bryan
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> _______________________________________________
> Openembedded-core mailing list
> 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/dc110d6b/attachment-0002.html>