\documentclass[10pt,final]{beamer}
\mode<presentation>
\usetheme{debian}
\usepackage{debiantutorial}

\title{Multiarch in Debian: six months (or six years) on}
\author[]{Steve Langasek\\{\small\texttt{vorlon@debian.org}}}
\date{\footnotesize 26 July 2011}

\begin{document}

\frame{\titlepage}

\begin{frame}
\frametitle{Multiarch in Debian: 6 months (or 6 years) on}
\begin{quote}
\raggedleft
ia32-libs [is now] the biggest source package in Debian.\\
 -Tollef Fog Heen\pause{},
2005-07-10
\end{quote}
\end{frame}

\begin{frame}
\frametitle{Multiarch in Debian: 6 months (or 6 years) on}
The problem has been known for a long time; the solution is six years late
\end{frame}

\begin{frame}
\frametitle{Multiarch: recent history}
\begin{itemize}
\item May 2009: apt and dpkg maintainers agree on a package management spec
at UDS in Barcelona
\item Aug 2010: BoF at DebConf in New York proposed new directory names
\item Feb 2011: dpkg multiarch implementation (sponsored by Linaro) lands in
Ubuntu
\item Mar 2011: new directory names scrapped, but finalized (and normalized)
GNU triplets adopted
\item Apr 2011: Ubuntu 11.04 released with 83 libraries multiarched, +14 in a
ppa: enough to cross-install flash plugin
\item July 2011: 135 libraries multiarched in Debian
\pause
\item July 28 2011: ??
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Multiarch: key lessons}
Multiarch is an example of how to - and how not to - make large changes to
Debian that require coordination between many different maintainers.
\begin{itemize}
\item Use written specs to record \textbf{shared} understanding (not just
for Debian Policy)
\pause
\item Split your work into bite-sized deliverables (avoid needing to do years
of work before anyone else can see the results!)
\item Make it clear how people can help
\pause
\url{http://wiki.debian.org/Multiarch/Implementation}
\item There is nothing so permanent as a temporary solution.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Multiarch: so what?}
What does all this work (and waiting) get us?
\begin{itemize}
\item Cheap emulated environments - emulate only the parts you need to
\pause
\item Cross-compilation is no longer special - you get it for free!
\pause
\item Support for cross-grading a system from one architecture to another
(arm$\rightarrow{}$armel, i386$\rightarrow{}$amd64, armel$\rightarrow{}$armhf)
\pause
\item Better support for binary-only software
\pause
... the same support we're \emph{already} providing, now without impact on
the supportability of the main archive
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Multiarch: how to get involved} 
\url{http://wiki.debian.org/Multiarch/Implementation} gives all the 
details for converting shared libraries, the common interesting case
\begin{itemize}
\item use \texttt{dpkg-architecture -qDEB\_HOST\_MULTIARCH} to query the
name of the subdirectory for libraries
\item move shared libraries, static libraries, .so symlinks, pkg-config
files, .la files (... if you still need them), and plugin loader paths to
the new directory
\begin{itemize}
\item plugin loader path changes obviously require coordination between
related packages to manage the transition!
\item either Breaks, or searching both old and new paths
\end{itemize}
\item leave helper executables in /usr/lib (the "libexec" case)
\begin{itemize}
\item if the helper executables are binary, they need split into a separate
package
\item policy says you're already supposed to do this
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Multiarch: how to get involved}
packages that are dependencies of shared libraries because they ship
data or executables (such as the above -bin, -run packages) must be marked
\texttt{Multi-Arch: foreign}
\begin{itemize}
\item even if they're \texttt{Architecture: all}!
\item (see \url{https://wiki.ubuntu.com/MultiarchSpec} to understand why)
\item (see previous slide about using written specs)
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Multiarch: what lies ahead}
\begin{itemize}
\item -dev packages needed for cross-building
\begin{itemize}
\item Easiest to move .so, .la, .a, .pc at the same time we move shared
libraries
\item Policy allows this
\item But this is not enough to treat -dev packages as \texttt{Multi-Arch: same}
\item headers are sometimes architecture-dependent
\item we need to work through best practices for handling these, balancing
package maintainability against avoidable filesystem bloat
\end{itemize}
\item long list of libraries to convert before we can drop ia32-libs
\item several short lists that let us start picking off the
reverse-dependencies of ia32-libs (ping me if interested)
\item get multiarch support merged into dpkg (in parallel to everything above)
\item get downloading of i386 Packages files enabled by default on amd64!
\item handful of bugs to sort out with eglibc
\item make multiarch usable for upstreams
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Multiarch: the next level}
What we have in the archive already enables us to do lots of great things,
but this is only the first of the "bite-sized" deliverables!
\begin{itemize}
\item Is it time to have "partial" architectures?  (sparc64, ppc64, i686?)
\item Do we need an amd64 grub-pc package, or should we make amd64 systems
use the i386 one?
\item Can we have sanely bootstrappable cross-compilers in the archive
proper?
\item Do we want to use cross-compiling by default on autobuilders?  For
bootstrapping new ports \textbf{directly} via the archive?
\item Can we solve the use of \texttt{Architecture: all} packages in the
archive that can only be built on one architecture?  (E.g., firmware packages
for emulators)
\item The implementation is easy, the policy is hard
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Multiarch: excelsior}
The future of multiarch is wide open - and it's up to you
\end{frame}

\end{document}
