ubuntu-appstore-developers team mailing list archive

[Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx>]

On Tue, Sep 24, 2013 at 8:42 PM, Colin Watson <cjwatson@xxxxxxxxxxxxx> wrote:
>>
>> 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 ...

We have no plans of implementing anything in click, sorry if it came
out that way. This discussion is mostly to build the infrastructure on
the server-side to support it when it is available in click itself,
and to open up the topic so everyone who's responsible for the
different pieces can chime in.
Since we don't yet scan packages, this first pass will be users
manually entering what architectures that specific upload supports,
nothing else. We can move forward with this without defining what goes
into the manifest file, and that would still be enough for us to
pre-filter architecture on searches and make sure that people are only
being showed what their device will run.


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

We're not parsing it and since the store is currently still in beta
phase, we can break compatibility with whatever we need. I started a
branch for our review script to require a certain version of click or
newer to support changes like this.


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

Right. Whatever works for you and Jamie, we'll implement. Changing
these things around is pretty easy, even if we had to for some reason
re-process everything's that's already been uploaded.
Just let us know. In the mean time, we have some work to keep us busy
on the server adding the right tables, exposing them in the UI, making
sure that data is pushed to the index, etc.
The naming of the files we can pop on later.


-- 
Martin