On 02/09/2015 10:59 AM, Benjamin Zeller wrote:
Am 04.02.2015 um 15:35 schrieb Michał Sawicz:
W dniu 04.02.2015 o 15:16, Zoltán Balogh pisze:
One possible side thought for that feature could be to somehow let
the
app consumer skim the used binaries out from the fat packages.
Because a real fat package can get really fat :) imagine an app
with 6
or 9 builds in it.
Oh yeah, that's for sure, we need to make everything shared as much as
possible.
If we are going down that path, the stores responsibilty must be to
split up the
fat package and only deliver the parts required for the specific
client.
Why should a armhf 15.04 device download binaries for i386 14.10 and
i386 15.04.
That is a waste of bandwith AND space on the end users device....
This sort of eliminates the point of a fat package. Why go through
the trouble of creating a fat package only to have the store then
tear it back down and create individual versions of the package again?
From a developer perspective we need to
1) be able to easily build for multi-arches
2) be able to upload the resulting click package(s) into the store
Having a click build by default for all the arches we specify (a fat
package) in the manifest would be excellent. Only one package to QA,
upload, test, etc. This meets the requirements above.
Conversely however, allowing multiple clicks for an app in the store
also meets the developer requirements above, so long as it's easy
enough to build the multiple clicks (think one click build for
multi-arch).
