Right, so ideally it would be in the device-specific tarball. Is this doable the way it's set up now though? I thought the device tarball was currently only the android bits.
On Wed, Jan 15, 2014 at 7:28 AM, Sergio Schvezov < sergio.schve...@canonical.com> wrote: > > On 14/01/14 19:46, 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. >> > > 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. > > > > -- > 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 >
-- 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
