ubuntu-phone team mailing list archive

[Christian Dywan <christian.dywan@xxxxxxxxxxxxx>]

On 09.02.2015 23:01, Sergio Schvezov wrote:
> On lunes, 9 de febrero de 2015 19h'46:44 BRST, Nicholas Skaggs wrote:
>> 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).
>
> It is better to have single package in cases of big packages as well.
> There's a Java application in the store and I guess it could benefit
> from separate packages.
>
> It doesn't have to be one or the other, give the developer the choice.
> The user only really cares if it works and how much space it's going
> to take up.
And give the developer reliability. You don't want the store tear apart
your files, making it impossible to verify it's actually your build, and
possibly even breaking it  AFTER you did all the testing you possibly
could. You can't do QA with something that is a moving target.

If there's actual concerns on space, the store needs to allow
arch-specific uploads.

Just my 2 cents,
    Christian

Attachment: signature.asc
Description: OpenPGP digital signature