DescriptionAdam Williamson
2018-02-24 04:15:15 UTC
I'm not 100% sure if this is considered a bug, but it was certainly at least *unexpected*.
We recently added an 'installpkg system-logos' directive to lorax (it turned out in the end we didn't need to, but that's another story). Doing this caused all install attempts to fail, because lorax would attempt to install *both* fedora-logos and generic-logos. Both those packages do provide system-logos, but they also conflict with each other.
I dug into why this is a bit more. lorax installpkg is basically backed by this line:
pkgnames = [pkg for pkg in dnf.subject.Subject(p).get_best_query(self.dbo.sack).filter(latest=True)]
where 'p' is the requested identifier. So in this case, lorax does:
pkgnames = [pkg for pkg in dnf.subject.Subject('system-logos').get_best_query(self.dbo.sack).filter(latest=True)]
and what it gets back from dnf is a list of items (I think hawkey package objects?) including both fedora-logos and generic-logos.
lorax takes the list that get_best_query gives it, and tries to install all the packages in it. So this is why the conflict occurs: basically lorax is asking dnf "hey give me system-logos packages" and dnf says "oh okay those are fedora-logos and generic-logos" and lorax says "oh ok i'll install fedora-logos and generic-logos then", and...boom.
So, I figured I'd at least file a bug to highlight this behaviour and see who thinks what about whether this should be 'solved', and if so, where.
I think that I answered all questions in bug #1548586. Please if the information is insufficient, don't hesitate to reopen the bug report.
Additionally, get_best_query() returns all packages that fit to provided subject p. Then solver after filling dnf.base.goal and performing dnf.base.resolve() can choose one from provided possibilities (query from get_best_query()).
*** This bug has been marked as a duplicate of bug 1548586 ***
I'm not 100% sure if this is considered a bug, but it was certainly at least *unexpected*. We recently added an 'installpkg system-logos' directive to lorax (it turned out in the end we didn't need to, but that's another story). Doing this caused all install attempts to fail, because lorax would attempt to install *both* fedora-logos and generic-logos. Both those packages do provide system-logos, but they also conflict with each other. I dug into why this is a bit more. lorax installpkg is basically backed by this line: pkgnames = [pkg for pkg in dnf.subject.Subject(p).get_best_query(self.dbo.sack).filter(latest=True)] where 'p' is the requested identifier. So in this case, lorax does: pkgnames = [pkg for pkg in dnf.subject.Subject('system-logos').get_best_query(self.dbo.sack).filter(latest=True)] and what it gets back from dnf is a list of items (I think hawkey package objects?) including both fedora-logos and generic-logos. lorax takes the list that get_best_query gives it, and tries to install all the packages in it. So this is why the conflict occurs: basically lorax is asking dnf "hey give me system-logos packages" and dnf says "oh okay those are fedora-logos and generic-logos" and lorax says "oh ok i'll install fedora-logos and generic-logos then", and...boom. So, I figured I'd at least file a bug to highlight this behaviour and see who thinks what about whether this should be 'solved', and if so, where.