Original report by kwizart: https://pagure.io/copr/copr/issue/1 ============================================================================= I would like to have support for multilibs in the copr x86_64 repository. The problem is that I'm testing a build library that is completely relevant for 32bit userspace. (aka mesa-libGL in kwizart/glvnd copr repo). If such support is missing, users will experience a dependency breakage and will not be able to install my copr repo. That would be very needed in order to better test glvnd enabled mesa until fedora adds support for it. Since the corp build jobs between x86_64 and i686 seems unrelated (thoses seems to be separate tasks), I expect there is a need to have an option to enable so that a basic multilib support can be computed and the appropriate libraries copied (or better hardlinked) into the x86_64 repository. I expect that copying ../i386/*-devel and every arched dependencies from the -devel will be enought for a basic multilib support. Or is there other option ? Thx
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.