<div dir="ltr">Isn&#39;t it enough to set RPROVIDES/RCONFLICTS/RREPLACES combo to say that eudev really replaces old udev even when the package version is lower.<div><br></div><div>This used to fix such upgrade-path issues before, but I&#39;ve stopped testing them long time ago.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 5:26 PM, Bryan Evenson <span dir="ltr">&lt;<a href="mailto:bevenson@melinkcorp.com" target="_blank">bevenson@melinkcorp.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<div><div class="h5"><br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:openembedded-core-bounces@lists.openembedded.org">openembedded-core-bounces@<wbr>lists.openembedded.org</a><br>
&gt; [mailto:<a href="mailto:openembedded-core-bounces@lists.openembedded.org">openembedded-core-<wbr>bounces@lists.openembedded.org</a><wbr>] On Behalf<br>
&gt; Of Bryan Evenson<br>
&gt; Sent: Tuesday, May 16, 2017 2:01 PM<br>
&gt; To: <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
&gt; Subject: [OE-core] eudev: opkg not automatically upgrading from udev to<br>
&gt; eudev<br>
&gt;<br>
&gt;<br>
&gt; I have an image based on core-image-minimal that uses sysvinit for init and<br>
&gt; opkg for package management.  I am doing some upgrade testing and I see<br>
&gt; an issue with eudev.  I am testing upgrading an image that was built under<br>
&gt; dizzy to my latest image built under morty.  I&#39;m first testing that all the correct<br>
&gt; packages and new dependencies are correctly being identified for upgrade<br>
&gt; by running &quot;opkg update; opkg upgrade --download-only&quot; from the<br>
&gt; command line and comparing what is in the opkg cache directory with what<br>
&gt; was available.  All packages except eudev and udev-cache are being<br>
&gt; downloaded for upgrade.<br>
&gt;<br>
&gt; I ran the opkg upgrade again with the -V4 option for additional debug output<br>
&gt; Here&#39;s what I saw in one section regarding udev:<br>
&gt;<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: Best installation candidate for<br>
&gt; udev:<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: apkg=udev nprovides=2.<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: Adding eudev to providers.<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: Adding udev to providers.<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: eudev arch=armv5e<br>
&gt; arch_priority=41 version=3.2.<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: udev arch=arm926ejste<br>
&gt; arch_priority=51 version=182.<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: Candidate: udev 182.<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: 2 matching pkgs for<br>
&gt; apkg=udev:<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: eudev 3.2 armv5e<br>
&gt; pkg_hash_fetch_best_<wbr>installation_candidate: udev 182 arm926ejste<br>
&gt; opkg_upgrade_pkg: Comparing visible versions of pkg udev:<br>
&gt;         182-r9.9 is installed<br>
&gt;         182-r9.9 is available<br>
&gt;         0 was comparison result<br>
&gt; opkg_upgrade_pkg: Package udev (182-r9.9) installed in root is up to date.<br>
&gt;<br>
&gt; I&#39;m assuming the problem is that udev is version 182 and eudev is version 3.2<br>
&gt; and that opkg doesn&#39;t think udev needs to be upgraded.  Is there an<br>
&gt; RDEPENDS that needs to be added somewhere so opkg sees that it needs to<br>
&gt; upgrade udev to eudev?<br>
<br>
</div></div>I made some changes and now both eudev and udev-cache are being pulled in on upgrade.  However, I&#39;d like a second opinion that what I did was reasonable.<br>
<br>
First, I created eudev_%.bbappend in my private layer and added &quot;PE = &quot;1&quot;&quot; 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.<br>
<br>
Does this sound reasonable?  Is there a better way to do the same thing?<br>
<br>
Thanks,<br>
Bryan<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; Thanks,<br>
&gt; Bryan<br>
&gt; --<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Openembedded-core mailing list<br>
&gt; <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
&gt; <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</div></div></blockquote></div><br></div>