That's true, of course. Even though it also depends on how the build
process works. If it produces clicks for all targets at once, then
that's as easy as building one fat package. If we need to build all of
them separately, that will require much more manual user interaction.
Btw, I think we should also keep in mind what it is like when we send
out pre-release click packages to testers who install them manually.
I'm sure not everyone would know which click package of the, let's say,
five different ones is the one they need to install.
Am Mo, 9. Feb, 2015 um 6:01 schrieb Benjamin Zeller
<benjamin.zel...@canonical.com>:
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
<justcara...@carakas.be>:
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.zel...@canonical.com> 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
Post to : ubuntu-phone@lists.launchpad.net Unsubscribe
: https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
