ubuntu-phone team mailing list archive

[Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>]

Well the only part you have less work is the uploading part.
You still need to build and test your app for every 
architecture/framework you want to support....

Am 09.02.2015 um 17:52 schrieb Niklas Wenzel:
> Well, that might solve the problem in some way, but to be honest I 
> don't really want to go through the building, testing and uploading 
> process for multiple click packages. One is enough...
>
> Am Mo, 9. Feb, 2015 um 5:24 schrieb Jelmer Prins <justcarakas@xxxxxxxxxx>:
> > isn’t it than a better solution to be able to be able to upload 
> > multiple click packages for an app ? And than let the store look if 
> > it has a click package for the targeted device ? that way you only 
> > download what you need This could also help to back port fixes to 
> > frameworks your current release doesn’t support anymore greetz 
> > JustCarakas On 09 Feb 2015, at 17:12, Benjamin Zeller 
> > <benjamin.zeller@xxxxxxxxxxxxx> wrote:
> >
> >     Am 09.02.2015 um 17:06 schrieb Michał Sawicz:
> >
> >         W dniu 09.02.2015 o 16:59, Benjamin Zeller pisze:
> >
> >             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. 
> >
> >         We don't want to touch the packaged app when the user uploads
> >         it to the store. It's signed by the developer and we can't
> >         touch it thus. 
> >
> >     Thats unfortunately true :/. Didn't think of that...
> >
> >             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.... 
> >
> >         I'd say that applies to single-framework fat packages just as
> >         well (i386 vs. amd64). 
> >
> >     Absolutely. Could we probably at least strip the click
> >     application from unneeded frameworks and architectures when
> >     installing? So we do not fill up the device with files that are
> >     never ever touched again? At least the std paths we know about
> >     e.g. /lib/<arch>
> >
> >             Also packaging a app like that is really not easy even
> >             with UI support. I imagine a QtC project with > 10
> >             buildconfigurations is not fun to handle.. 
> >
> >         I'd say 2 or 10 is probably not that big of a difference, if
> >         done right. 
> >
> >     At least it won't make things easier ;). -- Mailing list:
> >     https://launchpad.net/~ubuntu-phone
> >     <https://launchpad.net/%7Eubuntu-phone> Post to :
> >     ubuntu-phone@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >     https://launchpad.net/~ubuntu-phone
> >     <https://launchpad.net/%7Eubuntu-phone> More help :
> >     https://help.launchpad.net/ListHelp 
> >
> > --
> > Mailing list: https://launchpad.net/~ubuntu-phone 
> > <https://launchpad.net/%7Eubuntu-phone> Post to : 
> > ubuntu-phone@xxxxxxxxxxxxxxxxxxx Unsubscribe : 
> > https://launchpad.net/~ubuntu-phone 
> > <https://launchpad.net/%7Eubuntu-phone> More help : 
> > https://help.launchpad.net/ListHelp