On Thu, Apr 7, 2022 at 5:37 PM Martin Jansa <[email protected]> wrote:
> On Thu, Apr 7, 2022 at 11:10 PM Richard Purdie < > [email protected]> wrote: > >> On Thu, 2022-04-07 at 16:48 +0200, Martin Jansa wrote: >> > I've tried with rpm and surprisingly it works and dnf was able to >> > install python3-cryptography-ptest in the image (even after bumping PR >> to r1 - >> > n python3-cryptography-vectors recipe). >> > >> > But still not clear why it works and if it's expected behavior. >> > >> > In fresh fedora:37 docker image with rpmdevtools installed I see: >> > >> > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r1 >> > 36.0.2-r0 < 36.0.2-r1 >> > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0 36.0.2-r0 >> > 36.0.2-r0 == 36.0.2-r0 >> > [root@aaa509e35d1f /]# rpmdev-vercmp 36.0.2-r0.0 36.0.2-r0.1 >> > 36.0.2-r0.0 < 36.0.2-r0.1 >> > >> > But I'm not familiar with dnf/rpm to see how the versioned runtime >> dependency >> > is handled during installation (isn't it resolved by the same libsolv >> as what >> > opkg is using now by default as well? >> > >> > + Alejandro in case it should be fixed in opkg somehow. >> >> I did a bit of digging on this and it is basically a difference in >> behaviour >> between the debian and rpm worlds. >> >> In Debian, "1.2.3" != "1.2.3-r0" but in the rpm world, a recipe saying "(= >> 1.2.3)" with PR=r0 is ok and matches. >> >> We can't obtain the PR of another recipe when writing package manager >> fields so >> this is rather tricky to solve. Debian doesn't support any kind of >> wildcard in >> the versioning either. I've proposed a patch which uses >= and << to >> force a >> very specific range which is horrible but the best I could come up with. >> I'm >> open to other ideas... >> > > For this specific case the cure is almost more horrible than the issue > this commit was trying to prevent, but I agree that being able to depend on > version might be useful elsewhere as well and your package*bbclass fix > helps with that. > > Thanks for looking into this. > If the pain (which is what I understand with limited investigation) is cryptography vs cryptography-vectors being in sync (already a painfully known problem) — I again propose merging the recipes. Now I think about PYPI_PACKAGE being extended to understanding lists… And I want a pony, with wings, and rainbow hair, and a horn. > Regards, > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#164150): https://lists.openembedded.org/g/openembedded-core/message/164150 Mute This Topic: https://lists.openembedded.org/mt/89849717/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
