← Back to team overview

ubuntu-phone team mailing list archive

Re: Device-Specific configs in debs

 

hi,
Am Freitag, den 17.01.2014, 16:47 +0000 schrieb John McAleely:
> On 17/01/14 16:38, Oliver Grawert wrote:
> 
> > our whole system is currently designed around the android lxc container
> > and libhybris for hardware interaction, once something else comes around
> > we can indeed change this (but will also need to change code), for now i
> > would say hardware support equals the android zip/container (even our
> > install process requires a modified android recovery)
> 
> Without a clear path to being device-specifc-but-not-android, I think we
> we push our 'common parts' to take the approach that they are aggregated
> sets of all the settings needed for all devices.
> 
> That might be fine while we are one team, managing a handful of public
> devices, even if it clearly seeds a long term problem.
> 
> It only takes one file to need to be device-specific, and also
> confidential-before-launch to require the 'common parts' bundle to be
> forked/patched in some way.
> 
> 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
specific, the display resolution related ones are there to work around a
missing feature (DPI detection), the udev rules and apparmor files are
there for developer convenience because it takes a lot more effort to
maintain them in the android tarball ...all of them could live in the
device tarball if we wanted...

i think it is moot to discuss non-android based HW until we have to
handle it, if an OEM with totally free driver stack comes around so that
we can use drivers without container this will change, but i doubt that
will happen in the near future ... even OEMs will have to build the
android zip today during their porting effort (or a paid team inside
canonical will do it for them) 

though there is work planned to make plain i386 linux images without any
android which will give us a push in cleaning up these seven files and
just provide a clean rootfs at some point 

ciao
	oli

Attachment: signature.asc
Description: This is a digitally signed message part


Follow ups

References