linaro-release team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

On Fri, Mar 11, 2011 at 09:18:29PM -0000, Scott Kitterman wrote:
> When will this dpkg change go into Debian?  If we go first is there some risk 
> that the 'final' library locations won't be quite final after all?

The library paths have been agreed with the Debian dpkg, eglibc, and gcc
maintainers; there should be no risk of change to the paths.

The one remaining point that's being discussed in dpkg upstream is the
precise form the dpkg on-disk database will take.  We currently have a
preliminary implementation in natty that can be safely migrated from, but if
there are further changes to the database format those will cause
significant migration pain if we switch too early.  So I'm currently waiting
for the current on-disk database to be signed off on upstream; I'm giving
this until Tuesday (Mar 15) to work its way through.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

-- 
You received this bug notification because you are a member of Linaro
Release Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/733501

Title:
  FFe: transitioning libraries to multiarch paths

Status in Ubuntu:
  New

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