BillNottingham/MultilibDraft

Changing how we handle multilib

Owner

• Names: BillNottingham, JeremyKatz, SethVidal, JesseKeating

Current status

• Targeted release: Fedora 8
• Last updated: [[Date(2007-07-13T15:41:24Z)]
• Percentage of completion: ??%

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.

• Pros:
• This will solve the main user-visible 'upgrade drawbacks
• Cons:
• None, really. May require some tricks to get upgrades right if packages are divided differently (see later.)

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.

• Pros:
• With more fixes, moves multilib selection to the client system
• Can be used to also denote 'has an initscript', 'contains icons', etc., leading to simplification of scriptlets
• Cons:
• Won't work on third-party packages
• Is a 'flag day' event
• Open questions:
• How to implement in RPM?
• Alternatives:
• Can be faked at runtime with a yum plugin, but that doesn't allow for packages to opt out or be explicitly tagged

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....

• Pros:
• Gives users the customization ability they currently want
• Cons:
• Need to select a default, which will be a subject of debate.
• How to wire this up in anaconda/kickstart, if at all?
• Is a 'flag day' event
• Open questions:
• How to handle upgrades?

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.

• Pros:
• Makes tree composition much easier
• Cons:
• WTF do we do for media?
• Is a 'flag day' event
• Have to backport changes to prior releases so upgrades DTRT

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.

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:

• Drop libraries in /lib, /lib64, /usr/lib, /usr/lib64, etc.
• Drop files in /etc/ld.so.conf.d pointing to their libraries in other

locations

• PAM modules in /lib*/security
• SASL modules in /usr/lib*/sasl2
• Put gtk engines in /usr/lib*/gtk-*/*/engines/
• Put input modules in /usr/lib*/gtk-*/immodules/ or

/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:

• gdb
• frysk
• systemtap
• systemtap-runtime
• ltrace
• strace

Assorted other things

• nspluginwrapper
• wine
• wine-arts
• libflashsupport
• valgrind

Comments

Community comments here - FirstnameLastname

---