ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxxxxx>]

On Tue, Sep 24, 2013 at 06:21:20PM -0300, Martin Albisetti wrote:
> On Tue, Sep 24, 2013 at 5:38 PM, Ricardo Kirkner
> <ricardo.kirkner@xxxxxxxxxxxxx> wrote:
> > Assumptions
> > - a click package can support one of the following architectures: armhf,
> > amd64, i386 or all (meaning a generic app that works on all architectures)
> > - a click app can support multiple applications by means of multiple click
> > packages (one for each supported architecture)
> 
> No, click packages will have to be implemented as fat packages to
> support multiple architectures. So only one binary per app, the binary
> can support multiple architectures.

Right.

One thing I need to point out: I have not yet defined how this is going
to work in click, and I am going to need to.  If anyone defines things
about the click format (including non-"x-"-prefixed manifest entries) in
other packages that really ought to be nailed down in click first, I'm
going to be rather unimpressed.  At least send me a merge proposal if
you do that ...

The main difficulties are:

 * somebody cowboyed an "architecture" key into lots of existing click
   packages' manifests without making sure it was an accepted part of
   the file-format spec first (it still isn't, largely because I'm
   anticipating this problem), and it's probably going to have to change
   to be at least potentially a list, or some such
 * we have to figure out what to do with the Architecture field in the
   control part of the package, which is parsed by dpkg; I suspect that
   the answer here is to lie and call fat packages "Architecture: all"
   from dpkg's point of view, but I need to do some validation work on
   this

Since the "architecture" field is there already, admit it: who's parsing
it?  It's not in the file-format spec, so technically I'm perfectly at
liberty to break its semantics without telling anyone, but I'd kind of
like to at least know.  Maybe it's better to have a new field name, or
have some kind of transitional mechanism.

> This opens up the question on how to name the file when you support
> multiple architectures (myapp_0.1_armhf-i386-amd64.click?). Maybe we
> don't expose the architecture in the file name?

I'd prefer to keep an architecture element personally - I think it's
quite possible that authors of packages containing very large amounts of
architecture-dependent code will still want to distribute separate
versions for each architecture, so I want to make sure the slot is
unambiguously there in the file name - but it doesn't have to be fully
descriptive.  "fat" or "multi" would do; the latter is already used by
at least one multiple-architecture-handling tool for Debian package file
formats, specifically mergechanges(1), so it would probably be my choice
if it doesn't cause anything to break.

The architecture is going to need to come from the manifest (and perhaps
temporarily the submission form, until the store learns how to run
"click info" over packages), not the file name.

> > - we will now have to allow uploading a new click package for an already
> > uploaded version, as long as it's for a new architecture
> 
> As per above, only one binary per app. If you want to support more
> architectures, you upload a new binary with a new version.

Yes, definitely.  Let's not get into the pain of editing existing
versioned files.

-- 
Colin Watson                                    [cjwatson@xxxxxxxxxxxxx]