ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Thu, 2014-05-01 at 18:28 -0400, Chris Wayne wrote:
> On Thu, May 1, 2014 at 5:16 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
> 
>         On Thu, 2014-05-01 at 17:01 -0400, Chris Wayne wrote: 
>         
>         > We currently have some upstart jobs that set certain env
>         > variables, like the dconf db/profile to use the customized
>         > dconf keys.  
>         
>         It seems like this should be the default, not something in the
>         custom tarball. Is there any reason we'd not want to enable
>         the custom DConf DB if it exists?
> None that I know of, I'd just prefer to have all customization bits in
> the tarball, instead of having some in the rootfs, and then others in
> the tarball. 

I'd agree that all the customization should be in the tarball, but the
parts that detect the customization and use it should be in the rootfs.
The distinction I'm making here is that the DConf database should be in
the tarball, but detecting and deciding to use it should be on the
rootfs.


>         > Also a carrier may want to enable/disable certain services
>         > (think 4g tethering) for example, 
>         
>         This seems like it'd be better handled with a DConf key for
>         that service. It's also allow it to be more dynamic.
>         
>         > or maybe a different provider for ubuntu-location-service.
>         
>         Here we should probably provide a way to add these via a click
>         package.
> Right, the actual installation of it would be in a click package, but
> I'd imagine which service to use would be in the form of an upstart
> override. 

No. Click packages can not and should not install files into the
filesystem, they are self contained. It is possible that they would
provide declarative hook that could be implemented by an Upstart job,
but the click package itself should be in no way dependent on or use
Upstart directly.


>         All in all, I'm not against Upstart having the feature, but
>         it's a big scary stick and basically an unsupportable
>         interface. If we change the signals or the job names in an
>         image update, suddenly that update breaks that customization
>         tarball and device, potentially in a hard to fix manner.
> 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.

Ted

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