(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 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. 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. 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". Cheers, -- Colin Watson [[email protected]] -- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
