ubuntu-appstore-developers team mailing list archive

[Loïc Minier <loic.minier@xxxxxxxxxx>]

On Wed, Jun 12, 2013, Daniel Holbach wrote:
> there were multiple discussions about fat packages and handling
> different architectures across the whole project already, but it seems
> like these need to get final agreement, documentation and maybe some
> work items.

Yeah, I think there were some exploratory chats, but not sure we have
any written-down plan on supporting native packages on multiple
architectures.

Let's try listing the different things we want to achieve; please
comment!


Currently, we experiment mainly with arch-independent packages (e.g. QML
apps with a manifest and some extra resources such as images) and these
should be the norm, but there will be "native" or "binary" apps too,
written in C/C++ with Qt or other toolkits, calling into the native
Ubuntu platform API; for instance these could be OpenGL games ported
from other platforms.

The two subproblems we want to resolve are around building/creating
these apps and distributing them.

== Building for multiple architectures ==

The main way we expect people to build applications would be through the
SDK which currently allows creating arch-independent QML apps, or native
C/C++ apps, but only for the current architecture.

To support multiple architectures in Ubuntu .debs, we have Ubuntu
buildds and PPAs for developers.

I think we will want to allow 3 mechanisms to build native apps on
multiple architectures:
1. build them yourself with the SDK; this will require providing
   cross-toolchains for other architectures, e.g. an ARM cross-toolchain
   to target armhf from QtCreator on an Ubuntu x86 install[1]

2. build them yourself with your own tools; that is, you are using a
   different compiler, build tool, or you're including binary blobs in
   your package such as third-party libraries; your binaries need to
   conform with the ABI expectations of the target architecture (e.g. ARM
   EABI for armhf)

3. a build service similar to PPAs; we could hack something on top of
   PPAs today, but ideally we'd refactor the Launchpad implementation in
   a way that you upload a source tree and get one or more .click
   packages out of the PPA, perhaps that even gets directly into the
   appstore in some way

What's less clear is how much effort each approach is, and which
priority we want to give to each of them.  Perhaps we would want some
concrete examples of native apps that we want to offer on the appstore
to device.


== Distributing native apps ==

There are multiple ways we could distribute apps, and perhaps each of
them might be useful in the short or long-term.

1. include lib/$triplet/* in the Click package itself and document in
   the manifest which architectures it supports; pros/cons:
   (-) there is a bit of wasted space because you would download large
       packages and install files for all architectures on the device[2]
   (-) need to have files for all architectures available at the time
       where you build the package
   (+) simple and straightforward to implement

2. fat package containing an x86 and an ARM version of the package; kind
   of similar to 1., but allowing to only install the relevant bits for
   your architecture; this would be a more cleanly implemented version
   of 1., but would come with the same disadvantage of downloading
   larger packages; it might be easier to group multiple builds into one
   fat package with this approach or to detect which architectures are
   supported; perhaps we don't need this approach though

3. separate packages for each arch; that is, app developer uploads
   ARM and x86 bits separately
   (+) allows decoupling uploads/fixes/updates by architecture
   (-) more work for the developers
   (-) some versions might be out of date
   (-) probably more complex to implement in appstore


Separately from the various approaches to distribution above, we
probably want to limit at the manifest + appstore levels which devices
see which apps based on their capabilities.  E.g. only show this app for
CPU fasters than this, or CPU which implement this functionality, or
devices with that much RAM, or such a physical screen.  These filters
aren't particularly high priority for our first iterations though.


Would love to read other people's thoughts on this!

   Thanks,


[1] we have cross-toolchains targetting armhf for i386 and amd64 today,
    but this would also need work with e.g. multiarch-installation of
    the SDK bits for armhf, or perhaps some way to bundle platform libs
    for x86 and armhf in the SDK
[2] we could have dpkg hooks to exclude lib/$other-triplets when
    installing
-- 
Loïc Minier