ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Mon, Sep 30, 2013 at 06:09:15PM -0300, Martin Albisetti wrote:
> On Mon, Sep 30, 2013 at 7:58 AM, Colin Watson <cjwatson@xxxxxxxxxx> wrote:
> > 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.

Just "0.4" - Click-Version is the file format version, not the version
of the click package itself.  But I don't think you need to go to any
special effort to reject uploads with earlier versions; I'm not even
sure you could build an "architecture": ["armhf", "amd64"] package with
click < 0.4.9, and if you do manage it then it'll have a malformed dpkg
Architecture field which I'm told at least the review scripts will
reject anyway.

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

I think the above is roughly my complete brain-dump on the subject - it
probably needs somebody a bit closer to how QML (for the plugins case)
and perhaps commercial applications (for the complete binaries case)
tend to work to figure out the details, although I'm interested in
reviewing the result.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]