BillNottingham/MultilibDraft

From FedoraProject

Jump to: navigation, search

Contents

Changing how we handle multilib

Owner

Current status

Current status

Currently discussing it.

Summary

We want to change how we handle multilib in Fedora.

Usage cases/rationale

Bob only cares about x86_64 - he does not want any i386 packages on his system.

Fred wants to make sure any i386 software he installs on x86_64 automatically runs, if the library is available, without having to think about it.

Joe wants to compose a Fedora distribution, without worrying about which packages should be included as multilib or waiting for those packages to have their dependencies resolved before creating that distribution.


Issues with how we currently do multilib

There are, as always, bugs. This attempts to list the fundamental architectural issues we currently encounter.

1. yum's behavior when selecting packages is inflexible Generally, yum's behavior is, 'install package for all available arches that match compatibility.' There are people who want more flexibility without resorting to excludes, or specific yum-basearchonly plugins.

1. The set of available multilib packages is determined at compose time Right now, mash determines what packages are available for multilib at tree composition time. It has some heuristics to determine this - devel packages, packages which put libraries in /usr/lib or /usr/lib64, and a small hardcoded list (debugging tools, etc.). However, this leads to various issues, such as apps included that realistically shouldn't be (pidgin, gnucash, perl, etc.). Moreover, the fact that it's done at compose time makes composing a very expensive operation.

1. Combine those two, and upgrades become tricky As package contents shift, the set of packages available for multilib shifts. When a package that used to be multilib is no longer multilib, this can often lead to upgrade failures.

1. rpm evaluates conflicts differently depending on context https://bugzilla.redhat.com/show_bug.cgi?id=190209

1. our package set has many conflicts in packages selected for multiarch Ranging from binaries in devel/library packages, to *-config scripts, to the horrors of doxygen.

1. debuginfo is just plain broken The packages conflict, and the debuginfo repositories are composed only for the base arch. (These issues are almost certianly related.) The net effect is that for arches such as ppc64, the debuginfo repo has serious problems.

Potential Solution

Any solution is probably going to involve tiering of multiple changes. Starting with the simple, and going from there:

1. Fix the packaging

For packages which currently fall into the multilib set, fix them so they don't conflict.

1. Tag packages with some sort of information as to their usage

Suggested tags would signify 'runtime library', 'development', and possibly others. These would be added at build time by RPM, via a script that performs analysis similar to what mash does now. Packages could, via a spec file flag, either opt out or explicitly tag a package as well.

1. Change yum to use these tags to determine whether to install packages as multilib

For example, if a user has configured yum to install 'runtime' packages, only libraries are installed as multilib. Users could select 'devel' as well, or 'none', or....

1. Have the multilib packages be their own separate repository

Once yum has more flexible selection criteria, we don't have to craft the repository to provide the right package set to yum. The obvious answer is to then not tweak the repositories at all - just have separate i386 and x86_64 repositories, for example.

yum, based on the configuration, can automatically enable the compat repository for any repository that has $basearch listed.

Things not solved by this combination of proposals: debuginfo

Test Plan

Install a x86_64 tree. Make sure it installs a reasonable multilib set by default, and also can be easily disabled.

Dependencies

Scope

Things that will need changed:

1. yum - to implement the plugin and any required bits 1. rpm - to describe a mechanism to tag packages at build time 1. mash - to not do multilib there 1. pungi - to pull the correct arches (all?) 1. anaconda - to enable whatever plugin and configuration we use by default 1. 'the build scripts' - with this, we can theoretically ship a single x86 (installation) disc. Live would still require separate images.

How do we determine multilib packages

Multilib packages come in various categories. The heuristics that mash uses, and which can be adapted, are:

Libraries

These can be easily tagged programmatically. Library packages:

locations

/usr/lib*/qt-*/plugins/inputmethods/

Debugging tools that must match the kernel

These are packages that, for example, should be installed as 64-bit even on architectures where 32-bit is the 'preferred' width for normal packages, so that they can properly interact with the kernel to debug binaries of both arches. The current list is:

Assorted other things

Contingency Plan

Documentation

Release Notes

Comments

Community comments here - FirstnameLastname

Retrieved from "https://fedoraproject.org/wiki/BillNottingham/MultilibDraft"