On Fri, Jan 17, 2014 at 3:50 PM, Ondrej Kubik <ondrej.ku...@canonical.com> wrote: > 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....
How can we solve the same issue when using a pure Ubuntu stack (without Android)? Guess using a separated partition to handle the device specific / OEM files would be the easiest way, only problem then is that you're not necessarily able anymore to generate the same image just consuming bits from the archive. Cheers, -- Ricardo Salveti de Araujo -- 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
