ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 14-01-14 05:46 PM, 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.
> 
> 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.