ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

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.

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

Attachment: signature.asc
Description: OpenPGP digital signature