linaro-release team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

Thanks Steve for the detailled plan.

"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? 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? The steps until here (and the transition document, of course) seem
low risk to me. As you said, there might be a potential dpkg db change,
but we only need to fix that for intra-natty upgraders, and it shouldn't
be too difficult. I agree with Kate that I'd like to have these changes
in well before beta, so that we can do the major testing rounds with the
new infrastructure in place.

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). gtk isn't needed
by flashplayer, but converting that early would be interesting because
it would test the robustness with runtime loaded platform specific
modules (/usr/lib/gtk-2.0/2.10.0/immodules/*.so and /usr/lib/gdk-
pixbuf-2.0/2.10.0/loaders/*.so) We should then leave this in the archive
for a few days, iron out the problems, and could then continue until
beta-2.

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?

Getting up to the point of flashplugin is  a very laudable goal, as this
is probably the #1 reason why people have ia32-libs installed. The flash
player has tons of vulnerabilities, and so far people are using it with
outdated libraries (which ia32-libs constantly is). So I agree that for
this benefit it is worth taking some risk here.

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