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.
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
