ubuntu-appstore-developers team mailing list archive

[Ricardo Kirkner <ricardo.kirkner@xxxxxxxxxxxxx>]

On Fri, Sep 27, 2013 at 5:06 PM, Martin Albisetti <
martin.albisetti@xxxxxxxxxxxxx> wrote:

> On Fri, Sep 27, 2013 at 4:44 PM, Ricardo Kirkner
> <ricardo.kirkner@xxxxxxxxxxxxx> wrote:
> > Alright, this is an update on the current status of the architecture
> support
> > for click packages in the server-side, before I land this code.
> >
> > When uploading a new version of the application the developer now has to
> > specify which architectures are supported by the provided binary. Right
> now
> > this is a multiple selection widget listing all architectures available,
> and
> > the developer has to select at least one.
> >
> > Based on the selected architectures for the uploaded binary, the click
> > package filename will end either in
> > - _all.click if more than one architecture was selected
> > - _<arch>.click if a single architecture was selected
> >
> > For existing applications, where we don't have the architecture data
> stored,
> > the files will still be ending in _unknown.click. We can address that
> later
> > if we need to change them.
> >
> > Once we have click package introspection working, we should be able to
> > extract architecture information from the click package directly, and
> remove
> > the selection widget.
> >
> >
> > The only thing that bothers me slightly is that if we have apps A and B,
> > where A supports armhf and amd64, and B supports amd64 and i386, both
> click
> > package names will end in _all.click (so it's not possible to tell the
> arch
> > list from the name, only if it's single or multi arch).
>
>
> We'd probably want "multi" when multiple architectures are supported,
> "all" when it's QML or something not arch-dependant, and the arch if
> it's just the arch. That will mean "multi" won't be terrible
> descriptive, but it's probably good enough for a file name not really
> being used.
>

So, since right now the architectures are defined in the server, should we
have an explicit 'all' architecture option? or should we use that when all
options have been selected and use 'multi' when more than one (but not all)
have been selected?

Also, for proper filtering I suppose the full architecture list is to be
sent to the click index, right? So that we can have queries per specific
arch, disregarding of the filename (ie, even if the name contains 'all' or
'multi', the click index would know the package supports armhf and amd64,
for example)