ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

We should still have as little as possible device-specific in
lxc-android-config though, shouldn't we?  I'm all for putting *everything*
device specific into the device tarball, otherwise it's simply not
maintainable.


On Thu, Jan 16, 2014 at 8:46 AM, Jamie Strandboge <jamie@xxxxxxxxxxxxx>wrote:

> 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/
>
>
> --
> 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
>
>