Bug 1393664
Summary: | [RFE] multilib support | ||
---|---|---|---|
Product: | [Community] Copr | Reporter: | Pavel Raiskup <praiskup> |
Component: | backend | Assignee: | Miroslav Suchý <msuchy> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | ajax, sergio |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-01-03 23:00:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Pavel Raiskup
2016-11-10 06:17:14 UTC
Having multilib support would be neat. What is needed is probably: 1. detect that built package is multilib candidate, and if yes: 2. put the results from i386 chroot also into x86_64 result directory The 1. is tricky, however. The code responsible for multilib detection for Fedora is IMO hard-coded into pungi. Maybe pungi can be "reused" easily, dunno. Maybe we can hack it so there would be python-pungi-libs to serve this purpose for copr? Pungi RFE: https://pagure.io/pungi/issue/502 (In reply to Pavel Raiskup from comment #1) > Maybe we can hack it so there would be python-pungi-libs to serve this > purpose for copr? Seems like there's https://github.com/Zyzyx/python-multilib exactly for this purpose! (In reply to Pavel Raiskup from comment #1) > Having multilib support would be neat. > > What is needed is probably: > 1. detect that built package is multilib candidate, and if yes: > 2. put the results from i386 chroot also into x86_64 result directory > > The 1. is tricky, however. It's entirely unnecessary too. Just put the built rpms from every arch in the same directory and stop using $basearch in the baseurl. This wouldn't match how Fedora's repositories are configured, but who cares? dnf will do the right thing. (In reply to Adam Jackson from comment #4) > It's entirely unnecessary too. Just put the built rpms from every arch in > the same directory and stop using $basearch in the baseurl. This wouldn't > match how Fedora's repositories are configured, but who cares? Probably every user of yum/dnf -- because size of the repository matters, sad but true. Is anybody else using this pattern so far? > dnf will do the right thing. ™ :-) (In reply to Pavel Raiskup from comment #5) > (In reply to Adam Jackson from comment #4) > > It's entirely unnecessary too. Just put the built rpms from every arch in > > the same directory and stop using $basearch in the baseurl. This wouldn't > > match how Fedora's repositories are configured, but who cares? > > Probably every user of yum/dnf -- because size of the repository matters, > sad but true. Is anybody else using this pattern so far? The size of the repository matters when you have bazillions of things in it, which is most of the reason why Fedora proper has multilib split up the way it does. Most coprs do not have this property, I would be surprised if the median number of packages in a copr was even in double digits. For example, the ajax/upstream copr at the moment has 32 packages, and primary.xml.bz2 is 26 kilobytes. Copying every rpm from every arch into the repo would make it an entire 52 kilobytes. This hardly seems worth making coprs unusable in combination with multilib. Whether "anybody else" uses this pattern is immaterial. The only thing that matters is what dnf will do when presented with such a repository, and since with such a repo dnf will be able to find 32-bit rpms to satisfy its needs, what dnf will do is _work_. The (In reply to Pavel Raiskup from comment #0) > Original report by kwizart: > https://pagure.io/copr/copr/issue/1 This has been eventually implemented (see the link) as new repofile available - referencing both i386 and x86_64 repositories. 'dnf copr enable' should automatically download that variant if it is called on multilib system. |