ubuntu-phone team mailing list archive

[Ondrej Kubik <ondrej.kubik@xxxxxxxxxxxxx>]

Hi

We should keep in mind that eventually Custom, Ubuntu, Device images will
land in separate partitions. This is essential for what Steve mentioned,
each partition will clearly define playground for entity responsible for
it's maintenance and updating. Customisation partition will be updated
independently by OEM/Carries. Ubuntu partition by us, and device partition
by OEM. Any overlaps will cause trouble for updates.
Copying files from device partition to Ubuntu partition is recipe for
disaster, even as separate folder. One day somebody will write update
script deploying entire Ubuntu system image, instead of delta, this would
instantly brick the phone, since first line of the update script would be
'format' ubuntu partition, nuking all device specific files...
Same way we will want customisation as separate partition, otherwise one
day Carrier will decide to push this brilliant update with new 100MB
bloatware app, which will eat free space in Ubuntu partition failing next
Ubuntu system update....

Also I'd like to get terminology right here.  Can we stop referring to
"device tarball"? Tarball is only one of the way we will deploy files to
the phone. There is no way we can use "device tarball" and recovery mode on
assembly line, where images will be blasted in with flashing tools. So for
sake of this discussing, let's not refer to any tarballs and focus on
partitions/filesystems.
Additionally  device tarball holds android system.img which is loop
mounted. Anything else I can accept in it is boot and recovery images for
given device, but nothing else. If there are any other device specific
files there, where are they gonna land? If in device partition aka
system.img, then they should be there already. Otherwise we will get to
point where we need to copy those files somewhere, and that is no go as
Steve mentioned.

So my vote would be, all device specific files should in device partition
as long as we can honour this. This is mounted to /system in Ubuntu so it's
easily accessible. And as mentioned before, ubuntu system should have hooks
and look there for device specific files.
There is no point to elaborate about each file we identified now, yes some
can be avoided, but we all agree there will be device specific files and
those need to live somewhere, and Ubuntu system image is wrong answer.
If in time we will reach point we will need to store device specific
libraries linking against libc, we should mod Android build scripts to make
it so. This should be easy anyway, since it's already building for various
host platforms.

Oli about development hindering, I don't agree with you.
device/adroid image is just another mounted image, why not provide simple
tool which will mount device image as writable, same way we provide this
for Ubuntu image? Them just push your modified file to /system/..... No
need to compile android bit. It's same as what you are doing now. You also
don't recreate Ubuntu image to test your new config file.
Again try to think of it, that one day those should be two separate
partitions, rather than loop mounted image living inside another image....

Ondra


On Fri, Jan 17, 2014 at 4:47 PM, John McAleely
<john.mcaleely@xxxxxxxxxxxxx>wrote:

> On 17/01/14 16:38, Oliver Grawert wrote:
>
> > our whole system is currently designed around the android lxc container
> > and libhybris for hardware interaction, once something else comes around
> > we can indeed change this (but will also need to change code), for now i
> > would say hardware support equals the android zip/container (even our
> > install process requires a modified android recovery)
>
> Without a clear path to being device-specifc-but-not-android, I think we
> we push our 'common parts' to take the approach that they are aggregated
> sets of all the settings needed for all devices.
>
> That might be fine while we are one team, managing a handful of public
> devices, even if it clearly seeds a long term problem.
>
> It only takes one file to need to be device-specific, and also
> confidential-before-launch to require the 'common parts' bundle to be
> forked/patched in some way.
>
> I think that is a genie we would rather not let out of the bottle. As
> you note, there are already 7 cases where device specifics are needed. I
> assume that as we gain more devices, that number will grow, even if we
> also act to add generic abstractions into the common parts to manage
> those device specifics.
>
> J
>
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>