#502 Provide some API which could be used to detect that RPM package is multilib candidate
Closed: Invalid 6 years ago Opened 7 years ago by praiskup.

Something like python-pungi would be useful for Copr and:
https://bugzilla.redhat.com/show_bug.cgi?id=1393664

At the beginning, please don't make it too much sophisticated (1:1 replacement for the actual detection mechanism would be too much work). Something which analyses file list/provides of particular binary RPM would be useful. See also #500.


News for me, so FTR: RPM has long-time opened bug https://bugzilla.redhat.com/show_bug.cgi?id=653744 discussing something similar.

There is python-multilib library extracted from mash that implements the rules for whether package should be multilib. In the future pungi will move to use it as well.

You can not tell if a package is mutilib just by looking at it in isolation. You have to consider it in the context of a whole set of packages. For things built upon a different base you have to also consider things in the base. Even then you might hit issues where a package wants to be but can't because some Requires in a base repo is not multilib. Multilib white and black lists can effect it. Which are different between different repos

I would appreciate examples here, really. I fail to see why some general algorithm + white/blacklist + #500 for additional cases doesn't solve everything.

Can you please explain to me how you think multilib actually works.

I got your point in previous message, sorry. This bug report is not about having "API" for package in isolation. Yes -> having a build results (say a full build in koji, brew or copr) I want to see whether RPM is or is not multilib candidate. As @lsedlar pointed out, python-multilib might go the right direction though dunno how good that code is.

For rhbz#1393664, it would be enough to have something like find-multilib-packages dirA-x86_64 dirB-i386 command but python API would be much more useful.

can you make your request much clearer please. Every single package is a multilib candidate.

multilib is difficult and nasty. There is multiple different multilib types with different behaviours. the way it works in mash and pungi etc is to determine the set of packages that meet the policy and white and black lists. That is the easy bit, we then use yum to resolve dependencies to ensure that all packages are installable. So you can never really know if a package is multilib or not unless you go through the full cycle of a compose.

Having directories of packages is insufficient to determine if a package is multilib or not. you need to know the multilib policy used, you need to know what is white and black listed, you need to know the full base repo if it is not the base OS, and then you need to make sure all the dependencies are installable.

the way it works in mash and pungi etc is to determine the set of packages
that meet the policy and white and black lists. That is the easy bit,

Library with that functionality is needed from my POV.

we then use yum to resolve dependencies to ensure that all packages are
installable.

I don't think this is somewhat important IMO .. not doing that check means
"just" non-installable package (ugly thing, but there are other packages
not-installable because of packaging bugs). So why to do this in pungi?

Having directories of packages is insufficient to determine if a package is
multilib or not. you need to know the multilib policy used, you need to know
what is white and black listed

If there was an API, those are just parameters for the function.

you need to know the full base repo if it is not the base OS, and then
you need to make sure all the dependencies are installable.

Ideas: What tool check other (non-multilib) packages whether those are
installable? Could we check multilib-packages there too?

Maybe the issue is that finding multilib packages is done too late (at
compose time) but it should be done rather very early (without relying on
full base repositories).

You can not figure out multilib packages without doing the compose, the reason being dependencies change.

TBH, I don't understand. How multilib package differs from regular package here? Do we check package install-ability in pungi, too?

Well, I'm not sure now ... How pungi/multilib.py is related to mash/multilib.py? Should I report this against mash?

the way it works in mash and pungi etc is to determine the set of packages that meet the policy and white and black lists. That is the easy bit,

Library with that functionality is needed from my POV.

That's exactly what python-multilib library does.

How pungi/multilib.py is related to mash/multilib.py

Historically Pungi had it's own implementation of the logic, which should be almost similar to what mash had, but of course there are some differences. The code from mash was exctracted into python-multilib library so that it can be reused. New code in Pungi that uses DNF does actually use python-multilib.

Pungi currently does not provide any Python-level API. I don't think it's a good idea to start doing that. The original request is satisfiable by using python-multilib, so I will close this issue.

Metadata Update from @lsedlar:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata