ubuntu-appstore-developers team mailing list archive

[Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx>]

On Mon, Sep 30, 2013 at 7:58 AM, Colin Watson <cjwatson@xxxxxxxxxx> wrote:
> (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

Woohoo!  thank you.


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

Right, so the store renames files, so it doesn't care about what it
was named on upload, but we do care what to rename it to. This should
be part of Ricardo's current changes.
We also need the client to send the architecture to the server so we
can filter on that. Roberto, Alecu, can you guys sneak that in?


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

Is it specifying 0.4.9 as the click-framework, or is it still 0.4?
Last I checked it was only outputting major versions in the manifest
file. It's fine, it's just that otherwise we can't really reject
uploads with older versions.


> 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".

Cool. Do you have any further thoughts or documentation on how this
should work?  We need to find an owner for this piece to close the
circle, although it seems the SDK team is a bit swamped at the moment.
Maybe if we can document what we need more clearly it'll be easier to
find an owner.


-- 
Martin