ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

(FAO Ricardo Kirkner, although I thought this was worth a new thread.)

I've implemented the core of "fat package" support (that is,
architecture-dependent packages that contain support for more than one
machine architecture) in click 0.4.9, which I'm currently testing before
landing.  After Sergio pointed out that people had been using the
undocumented "architecture" manifest field on my advice which I'd
forgotten about, I decided that I ought to maintain
backward-compatibility for that.  The updated documentation is here:

  https://click.readthedocs.org/en/latest/file-format.html

The architecture elements of output file names are informational - click
doesn't rely on them - but they will be "all" for
architecture-independent, the architecture name for
architecture-dependent/single-architecture, and "multi" for
architecture-dependent/multiple-architecture.  click will of course
reject attempts to install fat packages that don't support the running
architecture.

Just to be explicit, here are the three cases:

  Package type     | "architecture" value | Output file name
  -----------------+----------------------+-----------------
  No compiled code | "all"                | NAME_VERSION_all.click
  Single arch      | "armhf"              | NAME_VERSION_armhf.click
  Multiple arches  | ["armhf", "i386"]    | NAME_VERSION_multi.click

Supporting this may require changes in review scripts, and perhaps on
the server if it cares about the file names.  Anything that parses the
"architecture" manifest entry will need to cope with the possibility
that it will be a list rather than a string, and anything that parses
the file name will need to cope with the architecture element being
"multi".  I hope nobody's parsing the Architecture field in the dpkg
control metadata - that's just there to keep dpkg happy - but it will
also be "multi" in the fat package case.  I would assume that the store
and the click scope will also need to be updated to check architecture
metadata appropriately.

I haven't bumped the file format version, since the "architecture" field
was previously undocumented and this should be backward-compatible with
all existing packages, but of course any packages created with the
"architecture" field set to a list will only work with click >= 0.4.9.

People interested in the SDK and in application launching should figure
out some conventions for how fat packages should be laid out and
launched ASAP.  Presumably QML plugins will need to go in
architecture-dependent subdirectories, and if people are shipping entire
binaries for each architecture (e.g. the many non-QML cases) then those
will also need to go in architecture-dependent subdirectories but
there'll need to be some kind of dispatching wrapper.

I would strongly recommend that the names of architecture-dependent
subdirectories should be chosen to match the way we lay out multiarch
libraries in /lib and /usr/lib; that is, the names should involve
triplets as printed by "dpkg-architecture -qDEB_HOST_MULTIARCH".

Cheers,

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]