It shouldn't live in /custom, the custom tarball is only for carrier-specific customizations. TBH it doesn't matter to me in which dir/partition this stuff lives, as long as it's not shipped in the rootfs image.
On Mon, Feb 10, 2014 at 10:20 AM, Jamie Strandboge <ja...@canonical.com>wrote: > On 02/10/2014 08:56 AM, Chris Wayne wrote: > > Jamie, > > Thanks for reviving this, it definitely needs more action. > > > > > > I don't think the plan should be to move it into a different deb package > shipped > > in the rootfs. I thought the plan was to ship everything > device-specific in the > > device tarball? (That is after all, the whole purpose of this thread :) ) > > > I don't have a strong opinion on this (though it sounds like others > might), but > for apparmor, I just need a decision on the directory and then I can move > the > existing hardware-specific policy to it. Do note, this directory must > exist and > will need to be created by apparmor-easyprof-ubuntu, which means that this > directory will exist on all systems with apparmor-easyprof-ubuntu > installed (ie, > desktop systems with the sdk installed now and all desktop systems once we > move > to unity8). > > Would it be acceptable to make (some part of) > /usr/share/apparmor/hardware/* > read/write via /etc/system-image/writable-paths so the device tarball can > unpack > there or is there some hard requirement that it must live in /custom? (I'm > not > super keen on /custom on desktop systems, but maybe that is exactly what we > want-- OEMs for desktop system could ship policy there too) > > > > > On Mon, Feb 10, 2014 at 9:52 AM, Jamie Strandboge <ja...@canonical.com > > <mailto:ja...@canonical.com>> wrote: > > > > On 01/17/2014 07:32 PM, Steve Langasek wrote: > > > On Fri, Jan 17, 2014 at 05:51:27PM +0000, John McAleely wrote: > > >> On 17/01/14 17:04, Oliver Grawert wrote:> hi, > > >>> Am Freitag, den 17.01.2014, 16:47 +0000 schrieb John McAleely: > > >>>> I think that is a genie we would rather not let out of the > bottle. As > > >>>> you note, there are already 7 cases where device specifics are > needed. I > > >>>> assume that as we gain more devices, that number will grow, > even if we > > >>>> also act to add generic abstractions into the common parts to > manage > > >>>> those device specifics. > > > > > >>> well, as you can see from the discussion none of these 7 files > *need* to > > >>> be in the rootfs tarball ... the bluetooth one should be chipset > > > > > >> Understood & agreed. I think I'm surprised that we are adding > stuff to > > >> the android tarball in any of these cases, rather than building in > > >> some sort of Ubuntu device specific tarball/image/partition/deb. > > > > > >> I think that most of these will be examples of Ubuntu choosing to > use > > >> a different userland stack to Android, and asking the Android > tarball > > >> to carry device configs for those sits oddly with me. > > > > > > To clarify, what we're talking about here is the android source > package, not > > > the android tarball per se. The android package in Ubuntu is the > point > > > where we gather up the contents for the recovery and boot > partitions, and > > > the loopback filesystem used for the container, all of which are > currently > > > android based. But we don't necessarily need to add these configs > to an > > > android tree in order to have them included in the correct > partitions. If > > > it's preferable, we could certainly have them live in the > lxc-android-config > > > source package, and have that spit out a binary package which the > android > > > source depends on when it builds its images. (But then you still > have the > > > two-stage build process to contend with, which involves rebuilding > the > > > android package anyway, at least until we start dealing with > non-android > > > devices.) > > > > > > > Now that the android 4.4 stack is is being tested, we are seeing > more of these > > hardware specific accesses. I feel like the thread sorta died > without clear > > direction on how to move forward. The current existing plan is to: > > > > * have apparmor-easyprof-ubuntu ship the > /usr/share/apparmor/hardware/* > > directories (so profiles can reference it) > > * move the existing policy from /usr/share/apparmor/hardware/*/* > into > > lxc-android-config as described in the bug[1] and previously on > this list[2] > > > > Is this still the plan of record or is something changing? > > > > [1] > https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1197133 > > [2] > https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037654.html > > > > > > -- > > Jamie Strandboge http://www.ubuntu.com/ > > > > > > -- > > Mailing list: https://launchpad.net/~ubuntu-phone > > Post to : ubuntu-phone@lists.launchpad.net > > <mailto:ubuntu-phone@lists.launchpad.net> > > Unsubscribe : https://launchpad.net/~ubuntu-phone > > More help : https://help.launchpad.net/ListHelp > > > > > > > -- > Jamie Strandboge http://www.ubuntu.com/ > >
-- 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
