ubuntu-phone team mailing list archive

[Christian Dywan <christian.dywan@xxxxxxxxxxxxx>]

On 10.02.2015 19:11, Benjamin Zeller wrote:
> Am 10.02.2015 um 17:02 schrieb Christian Dywan:
>> 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.
> True, BUT you still can safely assume that the files in
> /lib/arm-linux-gnueabihf
> will NOT be required on a i386, amd46 or ppc machine. So the click
> installer
> process should be able to strip those out. Why waste this space?
If it's click locally omitting a folder that is probably sensible, as
QtC would always install the exact same thing.

My concern is with having changes applied on the server side.
>> If there's actual concerns on space, the store needs to allow
>> arch-specific uploads.

Attachment: signature.asc
Description: OpenPGP digital signature