← Back to team overview

linaro-release team mailing list archive

Re: [Bug 733501] Re: FFe: transitioning libraries to multiarch paths

 

On Mon, Mar 14, 2011 at 08:00:02AM -0000, Martin Pitt wrote:
> "dpkg that implements support for the final library paths", "gcc and
> eglibc to use the paths", and "debhelper and pkg-config patches to
> support multiarch" will only enable additional library search paths, and
> thus our current libary packages should continue to work unmodified,
> right?

Correct.

> That is, with the exception of lib32ffi-dev and friends; do you know (by
> grepping Contents.gz or similar) that this is the complete list?

Yes, this is a grep for 'usr/(lib|include)/i686-linux-gnu' in i386 and amd64
Contents.gz.

> I don't think we are in a hurry to update the library stack by beta. We
> should,, upload a small set of central libraries (i. e. if something
> breaks, we _will_ notice), such as glib2.0, libx11, libxcb, libpcre, and
> libdl (all of which are required by libflashplayer.so).

I have a pretty good set of libraries bootstrapped at
https://launchpad.net/~vorlon/+archive/multiarch/, FWIW.  It's actually
enough to make flashplugin-installer cross-installable, but not
co-installable with a desktop yet.

> Question here: Once the new debhelper is in, will library packages will
> be built for multiarch compatible paths by default, or does this need to
> be enabled in debian/rules?

If using dh(1) and your package uses autoconf, you can switch to compat
level 9 and the package will build for multiarch paths by default.  It's not
safe to make this a completely automatic conversion:

 - a new pre-depends line needs to be added to the library to ensure that
   the virtual package 'multiarch-support' (provided by a compatible libc)
   is installed before we unpack libraries to the new path.
 - various embedded paths in debian/*.install, debian/*.links, etc will be
   invalidated, and not all of these will be detected at build time
 - patches may be needed for backwards-compatible plugin directory handling

So I'll make this as easy as possible to switch, but it's not automatic. 
And I see no good way to simplify the conversion for cdbs, which doesn't use
dh_auto_configure.  I guess cdbs could itself key on debian/compat >= 9 and
pass the --libdir option automatically, but as this behavior change would not
be nearly as discoverable with cdbs as it is with debhelper, I prefer not to
get too clever.

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

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?



Follow ups

References