ubuntu-phone team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

On Fri, Jan 17, 2014 at 10:44:26AM +0100, Oliver Grawert wrote:
> Am Donnerstag, den 16.01.2014, 18:16 -0800 schrieb Steve Langasek:

> > > even if we ship them in the android tarball (which as i mentioned
> > > elsewhere is a lot more effort to rebuild for a single change), they
> > > have to live in the rootfs after all.

> > In fact, we already patched udev once to look at picking up firmware files
> > from /vendor/firmware and /system/firmware before we decided this wasn't
> > actually necessary (and even harmful, because we didn't want udev loading
> > firmware if ueventd had already loaded it).  And we've even talked about
> > autogenerating udev rules from ueventd blocks (though this seems to have
> > stalled with me for quite a while... sorry about that).  I see no reason we
> > couldn't / shouldn't add /vendor/udev/rules.d, or even /run/udev/rules.d, to
> > the udev path to handle device-specific rules in a way that preserves our
> > hardware-independent, read-only rootfs.

> building the android package takes around 1h and requires you to download
> a ~250MB source package, building lxc-android-config takes 2 minutes and
> requires you to download 25KB

This is not really a fair comparison with respect to PES use cases.  The
android package build takes an hour, but at the end of that build it's done
building the binary filesystem images for multiple targets.  The
lxc-android-config package takes 2 minutes to build, but then you have to
wait for publishing and then feed those changes into a second stage build in
order to get the rootfs.  Also, when customizing the android source package
for a new target (which they will certainly need to do), PES can disable all
targets except for the one they care about, greatly reducing the build time.

> and it allows you to use the established merge proposal process via
> launchpad while changes to the android package have to be made to the
> phablet.ubuntu.com git tree (not sure if our gerrit instance is already up
> but up to now the only way to get patches included was by mailing someone
> who can commit to the git tree (or respectively the ML)...

That's an obstacle for getting changes upstreamed to the Ubuntu android
source package, yes.  OTOH, the android source package is explicitly one of
the places where PES reasonably *will* carry a delta against Ubuntu,
possibly on a per-device basis.  So in all likelihood, PES will be
maintaining their own git branches.

The lack of a clear workflow for submitting changes to the phablet.u.c git
repo is also a problem that I think we should be addressing, regardless of
anything else.

> doing development and testing a change to a device permission locally
> before uploading is proportionally a lot harder with the android
> package ... i would like to keep the changes as long as possible in the
> lxc-android-config package, even if we decide they should live inside
> the android package at some point ...

I understand that the android package is a bigger beast, and takes longer to
iterate locally.  But we should address that drag sooner rather than later,
because come 14.04, PES will not have the option of modifying the rootfs to
enable a new device.  So "at some point" should be now.

The right place for these customizations to live is in the device image, not
in the Ubuntu image, and we need to get serious about getting there.  The
surest way of doing that is holding ourselves to the same standard we expect
PES to hold to.

As for testing changes locally: while the android source package itself
takes some time to build, there's no reason that initial development of
these config changes should involve anything more than dropping a file onto
the image, rebooting, and repeating.  If you're concerned with testing the
whole build chain before uploading, well, that comes back to the fact that a
rootfs build also takes a lot more time than just testing
lxc-android-config.  If what you're trying to do is prove prior to upload
that the file change lands in the right place and works correctly, it
already takes quite a bit more time to do this right.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

Attachment: signature.asc
Description: Digital signature