← Back to team overview

ubuntu-phone team mailing list archive

Re: Device-Specific configs in debs

 


On 14/01/14 19:46, Alex Chiang wrote:
On Tue, Jan 14, 2014 at 2:21 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
On 01/14/2014 03:11 PM, Chris Wayne wrote:
Hi Guys,

So after looking at customizing powerd, I noticed several areas where we have
device-specific config files living inside deb packages.  As our idea of
customization has always been "one rootfs image for all devices", this seems a
bit problematic.  Just from a quick glance, I found the following
device-specific bits in the image (just a simple find / -name *maguro*):

...

/usr/share/apparmor/hardware/graphics.d/apparmor-easyprof-ubuntu_maguro
/usr/share/apparmor/hardware/video.d/apparmor-easyprof-ubuntu_maguro
FYI, apparmor-easyprof-ubuntu is currently shipping these itself, but that is
temporary and are intended to be moved to lxc-android-config as per:

https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037654.html
https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1197133
I'm sorry I missed this discussion. That is my fault.

That said, I do have a few questions about option #3 in the proposal.

------------------------------
Pros:
  - allows packages to drop files into the apparmor include directory if
    they don't use udev (eg, nvidia)
[...]
  - works fine on read-only images
------------------------------

What does "works fine" mean? Meaning that once the policy files are in
place in an ro image, then apparmor DTRT?

How do packages install files into the new include directory if the
image is ro? Is this done at image creation time?

While this works for now with our limited set of supported devices, it can
quickly become untenable once we start building images for OEMs in the future,
or if we get an influx of community builds.

I figured that a necessary part of building up the port was building up the udev
rules and apparmor accesses. OEMs/community builds would either fork
lxc-android-config or work within the existing hierarchies to ship files in the
appropriate directories. Both are shipped as debs and depart from the "one
rootfs image for all devices" goal of course.
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?

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.



Follow ups

References