ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 01/15/2014 04:34 PM, Jamie Strandboge wrote:
> On 01/15/2014 03:43 PM, Sergio Schvezov wrote:
>>
>> On 15/01/14 15:56, Jamie Strandboge wrote:
>>> On 01/15/2014 12:49 PM, Alex Chiang wrote:
>>>> On Wed, Jan 15, 2014 at 4:28 AM, Sergio Schvezov
>>>> <sergio.schvezov@xxxxxxxxxxxxx> wrote:
>>>>> On 14/01/14 19:46, Alex Chiang wrote:
>>>>>> Speaking with Steve Langasek yesterday, I got strong guidance that all
>>>>>> per-device configs really need to live in the customization tarball.
>>>>> Wouldn't adding that to the device specific tarball we ship solve that?
>>>> Yes, probably.
>>>>
>>>>> I thought the customization stuff was for customization stuff, while most of
>>>>> these files mentioned, unless I read through to fast, seem to be related to
>>>>> enablement.
>>>> I agree that most enablement-specific stuff would go into the device
>>>> tarball, and probably many of the existing examples cwayne provided
>>>> fall into that category.
>>>>
>>> How are the contents of the device tarball being applied? Before or after 'ro'?
>>> Something else? (sorry that I don't know the specifics here)
>>
>> Today it's just the android relevant bits and the image based upgrader does all
>> the work. I don't see why we couldn't add on to that (or create a new tarball
>> for these ubuntu side device specific bits).
>>
>> Here's a random device tarball:
>> https://system-image.ubuntu.com/pool/device-fdb17a59b347dad3d3f2415365de3879b410271cd304f592f65cb22a0ae70cb6.tar.xz
>>
> 
> One thing I forgot to mention on the apparmor bits is if the policy uses an
> #include file or directory, that include file or directory must exist.
> apparmor-easyprof-ubuntu makes sure that /usr/share/apparmor/hardware/* exist,
> which is why packages are then free to drop files in there. We could make the
> /usr/share/apparmor/hardware/* read/write on the image though, and the device
> tarball can sprinkle policy files in there. We could also ensure that
> /custom/.../apparmor/hardware/* exists on all images (apparmor-easyprof-ubuntu
> could create the directories), but that seems less tidy.
> 
> Also, the OEMs can of course work with us to add the policy to the packages
> before hand, but I understand this may not always work.
> 

Sergio reminded me that the unpack of the device tarball happens during the
update phase, before we go to readonly. As such, wouldn't it be reasonable to
stick with the current plan in:

https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037654.html
https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1197133

and ship the apparmor device accesses as part of lxc-android-config, and just
have OEMs drop their udev rules in /usr/lib/lxc-android-config/ and their
apparmor device accesses in /usr/share/apparmor/hardware/.... The porting
guide[1] has language for modifying lxc-android-config for these things
already-- perhaps it should be updated to include instructions on using the
device tarball mechanism?

[1]https://wiki.ubuntu.com/Touch/Porting#AppArmor


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature