On 7/15/19 8:08 AM, Tom Hughes wrote:
> On 15/07/2019 15:56, Zbigniew Jędrzejewski-Szmek wrote:
>> On Mon, Jul 15, 2019 at 11:52:50AM +0200, Mark Wielaard wrote:
>>> Could you explain a bit more how this (keeps) working? I think my
>>> mental model of how Fedora repositories work in the case of multilib
>>> devel packages is a bit flawed. At first I assumed that this suggestion
>>> would kill that. Because I was under the impression that it worked by
>>> having the i386 repository be part of the x86_64 package repository. So
>>> removing the i686 repositories would mean removing all 32bit packages
>>> from x86_64. But from your explanation above it seems that is not how
>>> it works. So if there are no i686 repositories, then where/how do the
>>> 32bit multilib packages come from?
>>>
>>> I think I am mixing up buildroots, koji targets, repositories in my
>>> mind.
>>
>> Let me second that request. It would be great if somebody could
>> summarize the steps that lead to 32bit packages being installable on
>> amd64 machines. I know how the beginning (compilation in the
>> appropriate chroot), and the end (dnf install foo.i686), but the
>> middle is hazy.
>
> It definitely doesn't work as Mark thinks because only a subset
> of the i686 packages are present in the x86_64 repository.
>
> I've never really been sure how it decides what packages to
> include but certainly the idea here that every 32 bit package
> that you might need on a 64 bit system is present is false
> because I actually have a list of additional packages that
> get copied over in my local mirror ;-)
So, this is how it works (as far as I recall off the top of my head):
You build a archfull package in koji. It's built for x86_64 and i686
(and the other arches).
pungi runs to compose things. It has a config (in pungi-fedora or bodhi
config) that tells it what to do for multilib. It has also config that
tells it what tag(s) to use for the compose, so it talks to koji and
asks about/gathers packages based on that tag.
Currently for rawhide that is:
multilib = [
('^Everything$', {
'x86_64': ['devel', 'runtime'],
})
]
# format: {arch|*: [packages]}
multilib_blacklist = {
'*': ['kernel', 'kernel-PAE*', 'kernel*debug*',
'dmraid-devel', 'kdeutils-devel', 'mkinitrd-devel',
'php-devel', 'java-*',
'httpd-devel', 'tomcat-native', 'php*', 'httpd',
'krb5-server', 'krb5-server-ldap', 'mod_*', 'ghc-*'
],
}
# format: {arch|*: [packages]}
multilib_whitelist = {
'*': ['libgnat', 'wine', 'lmms-vst', 'nspluginwrapper',
'libflashsupport', 'valgrind', 'perl-libs', 'redhat-lsb',
'yaboot', 'syslinux-extlinux-nonlinux', 'syslinux-nonlinux',
'syslinux-tftpboot', 'nosync', '*-static', 'apitrace-libs',
'fakeroot-libs', 'postgresql-odbc', 'mysql-connector-odbc',
'fakechroot-libs','mesa-vdpau-drivers', 'p11-kit-trust',
'mariadb-connector-odbc', 'compiler-rt',
'nvidia-query-resource-opengl-lib',
'ibus-libs', 'ibus-gtk2', 'ibus-gtk3',
'glib-networking'
],
}
So, that says to use the 'runtime' method of multilib, and then
explicitly add some packages and explicitly remove some. The orig idea
of 'runtime' was to allow runtime for i686 binaries on x86_64 platforms.
Pungi uses in turn the python-multilib package to do the actual
computations here, which you can see in:
https://pagure.io/releng/python-multilib/blob/master/f/multilib/multilib.py#_117
Basically it looks to see if a package has files in specific directories
(mostly runtime libraries) and returns a true or false if the package
should be multilibed. There is a bunch of cruft and corner cases in
there as well.
pungi then puts those i686 packages that are marked true into the x86_64
tree and creates the repo. x86_64 users can then install those i686
packages easily because they are in the x86_64 repos they already use.
None of the above needs a public, mirrored i686 repository tree. The
computation is done by pungi at compose time looking at all the i686
packages built in koji and tagged with the appropriate tag.
Did that help? Or make things worse... happy to try and expand or answer
any other questions about it.
kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
