That's why we have the -customized images tested by CI daily :) Any
update to the image that breaks customization would be found (and
fixed) before an image would be promoted. I don't see how having
custom upstart jobs makes it any more likely to fail than having
upstart jobs in the rootfs?
Heh, we're not going to have every customization for every device on
every carrier. It'd be nice, but we probably won't even have an
environment that could test things like customized location providers
(likely to require specific cell towers for instance). What's important
is that we keep the things that can be customized as a stable API, if we
can't guarantee that, we shouldn't allow it be customized.
All in all, we think this is something that a carrier/oem would
want/need to customize, and it'd be much easier to add now, than to
scramble later
So the more we talk about this, the more I think it's a bad idea. I'm
now of the opinion that we shouldn't provide this to customization
tarballs. If nothing else, because we don't expect to support Upstart as
long as we expect the customization tarballs to work.