On 14-01-14 05:46 PM, Alex Chiang wrote: > On Tue, Jan 14, 2014 at 2:21 PM, Jamie Strandboge <ja...@canonical.com> 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. > > And the customization tarball is only allowed to drop files into > /custom and $HOME.
Please don't put stuff in $HOME, that's not appropriate for system stuff like udev rules and device configs. > >>> I propose that we try and tackle this before it becomes a problem. Do we >>> have a >>> plan for this already? >>> >>> If we don't have a plan quite yet, as a first step, I propose that we patch >>> powerd and apparmor to look in XDG_DATA_DIRS instead of just /usr/share/ >>> for its >>> configs. If we do this, we can drop any needed configs into a custom >>> tarball >>> (which includes /custom/xdg/data, which is included in XDG_DATA_DIRS), and >>> therefore keep the rootfs as device-agnostic as possible. Does this seem >>> reasonable? XDG_DATA_DIR is a weird variable to be using for system daemons, IMHO. Where does it get set? I'm ok with defining a location, but mixing unrelated stuff with xdg doesn't sound like a good idea to me. Marc. -- 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
