ubuntu-phone team mailing list archive

[Jani Monoses <jani.monoses@xxxxxxxxxxxxx>]

I also agree the Android build tree should have these even though they
belong to the Ubuntu filesystem. The main reason is I am sure most OEMs
(and even some of us) prefer copying a few files around and have as direct
control over them as possible vs. building a .deb just for them with all
the PPA/image build hooks/hack-to-deploy cycle latency. In this custom case
the elegance of having source packages is trumped IMHO by pragmatism.
One way of doing it is having them set as part of the install and upgrade
steps. For the BQ we now unpack the Ubuntu zip and then have a script adb
push over the dev specific files to the Ubuntu root. So it does not need to
be bind mounted or copied at Ubuntu boot time, no Ubuntu side logic is
needed. Something similar needs to be hooked into the system image upgrade,
so they do not get lost. Again, I agree this is not very elegant, but seems
the one that most 3rd parties could get on board with as it requires almost
0 Ubuntu dev specific knowledge.

Jani


On Tue, Mar 4, 2014 at 5:45 PM, Ondrej Kubik <ondrej.kubik@xxxxxxxxxxxxx>wrote:

> I think we agree here, have device specific files in android system.img
> and bind mount this wherever it is needed during boot, so Ubuntu can see it.
> Custom package should not have anything hw specific
> Cheers
>  // Ondrej
>
> On Tuesday, February 11, 2014, Ricardo Salveti de Araujo <
> ricardo.salveti@xxxxxxxxxxxxx> wrote:
>
>> On Mon, Feb 10, 2014 at 1:35 PM, Sergio Schvezov
>> <sergio.schvezov@xxxxxxxxxxxxx> wrote:
>> >
>> > On 10/02/14 12:20, Jamie Strandboge 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)
>> >
>> > I was hoping for
>> > /system/etc/apparmor
>> >
>> > and have it bundled in the device specific repo in the android build,
>> but if
>> > it has exist on every install and must exist, then it doesn't seem that
>> > good.
>> >
>> > I would like to differentiate customization from hw enablement.
>>
>> Yeah, the ideal case here would be for the rules to be provided by the
>> system.img (android rootfs), and linked at some known place when
>> booting Ubuntu.
>>
>> Cheers,
>> --
>> Ricardo Salveti de Araujo
>>
>> --
>> Mailing list: https://launchpad.net/~ubuntu-phone
>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>