| 2011-03-11 20:52:07 |
Steve Langasek |
description |
(Filed without a package as there are a large number of packages affected)
With the next upload of dpkg, all the pieces will be in place to begin migrating our library packages to use the multiarch library paths for <https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-multiarch-support>. Individually the changes are low risk, the design has been agreed for over a year and I have aggressively tested in my ppa, but given the large number of affected packages and that this is ultimately a new feature rather than a bugfix, I think a FFe request is in order.
The overall plan is:
- push a new dpkg version that implements support for the final library paths
- bootstrap gcc and eglibc to use the paths (requires two gcc uploads with an intervening eglibc upload)
- push debhelper and pkg-config patches to support multiarch
- write up documentation for how to transition libraries, and announce this on ubuntu-devel
- convert the desktop library stack, one library at a time
The transition documentation is not written yet, because it partially depends on the finer details of the patch accepted by debhelper upstream.
My target for this cycle, which I believe is a realistic one, is to get flashplugin-installer:i386 co-installable with an amd64 desktop stack. This involves converting just over 100 library packages to the multiarch paths (highly parallelizable once we get going). Is this acceptable to the release team, and when do we need to be done with these changes for natty? before beta?
Risks I'm aware of with this transition:
- there are a handful of i386 packages in the archive that will be broken by the transition, because they install to the provisional library paths rather than the final ones we're using. These packages are lib32ffi-dev, libffi-dev, libhwloc-dev, liblouis-dev and liblouisxml-dev; they'll need to be fixed soon after we upload the new gcc.
- any library that loads architecture-dependent plugins / modules will need additional care to ensure that the system is never left in a broken halfway-transitioned state. For example, I have a patch to pam to prepend a multiarch module path to the standard /lib/security path; whereas for glib I only have it patched to look in the new gio modules path but *not* the old one, resulting in a long list of Breaks: in my ppa package that need to be sorted before release (preferably the same way pam solves it).
- ia32-libs will be broken in various ways by this change, because the libraries it rebundles will all come installed in the new multiarch paths and ia32-libs will need to adapt. (Debian policy 9.1.1 does not permit ia32-libs to install its contents to the multiarch paths; ia32-libs needs to be fixed up to make sure it only installs to /usr/lib32 instead to avoid file conflicts.) But even after this fix-up, there may be some regressions in functionality due to the changes in module paths mentioned in the previous point; this appears to affect glib and gtk in particular, for which ia32-libs ships symlinks under /usr/lib.
- this is very much a one-way transition. Once we start down this path in earnest, it will be infeasible to roll it back for natty.
Do I have the release team's blessing to proceed? |
(Filed without a package as there are a large number of packages affected)
With the next upload of dpkg, all the pieces will be in place to begin migrating our library packages to use the multiarch library paths for <https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-multiarch-support>. Individually the changes are low risk, the design has been agreed for over a year and I have aggressively tested in my ppa, but given the large number of affected packages and that this is ultimately a new feature rather than a bugfix, I think a FFe request is in order.
The overall plan is:
- push a new dpkg version that implements support for the final library paths
- bootstrap gcc and eglibc to use the paths (requires two gcc uploads with an intervening eglibc upload)
- push debhelper and pkg-config patches to support multiarch
- write up documentation for how to transition libraries, and announce this on ubuntu-devel
- convert the desktop library stack, one library at a time
The transition documentation is not written yet, because it partially depends on the finer details of the patch accepted by debhelper upstream.
My target for this cycle, which I believe is a realistic one, is to get flashplugin-installer:i386 co-installable with an amd64 desktop stack. This involves converting just over 100 library packages to the multiarch paths (highly parallelizable once we get going). Is this acceptable to the release team, and when do we need to be done with these changes for natty? before beta?
Risks I'm aware of with this transition:
- there are a handful of i386 packages in the archive that will be broken by the transition, because they install to the provisional library paths rather than the final ones we're using. These packages are lib32ffi-dev, libffi-dev, libhwloc-dev, liblouis-dev and liblouisxml-dev; they'll need to be fixed soon after we upload the new gcc.
- any library that loads architecture-dependent plugins / modules will need additional care to ensure that the system is never left in a broken halfway-transitioned state. For example, I have a patch to pam to prepend a multiarch module path to the standard /lib/security path; whereas for glib I only have it patched to look in the new gio modules path but *not* the old one, resulting in a long list of Breaks: in my ppa package that need to be sorted before release (preferably the same way pam solves it).
- ia32-libs will be broken in various ways by this change, because the libraries it rebundles will all come installed in the new multiarch paths and ia32-libs will need to adapt. (Debian policy 9.1.1 does not permit ia32-libs to install its contents to the multiarch paths; ia32-libs needs to be fixed up to make sure it only installs to /usr/lib32 instead to avoid file conflicts.) But even after this fix-up, there may be some regressions in functionality due to the changes in module paths mentioned in the previous point; this appears to affect glib and gtk in particular, for which ia32-libs ships symlinks under /usr/lib.
- this is very much a one-way transition. Once we start down this path in earnest, it will be infeasible to roll it back for natty.
- there has been no significant testing of multiarch enablement with package manager frontends such as synaptic, software-center, and aptitude, so it may not actually be feasible for users to turn on multiarch on the desktop for natty if they're using one of these frontends.
Do I have the release team's blessing to proceed? |
|
