ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

On Fri, May 2, 2014 at 4:37 PM, Steve Langasek <steve.langasek@xxxxxxxxxx>wrote:

> On Fri, May 02, 2014 at 10:45:11AM -0700, Alex Chiang wrote:
> > On Fri, May 2, 2014 at 9:15 AM, Ted Gould <ted@xxxxxxxxxx> wrote:
> > > On Fri, 2014-05-02 at 08:38 -0700, Alex Chiang wrote:
> > > > As a real world example of the services we might want to disable:
> > > >
> > > > - mediascanner service
> > > > - urldispatcher
> > > > - mtp-server
>
> > > Hmm, as the upstream for URL Dispatcher that makes me a bit nervous.
> Why?
>
> > We simply need a supported, maintainable way to disable arbitrary
> services.
>
> > If you are recommending that we have a conversation with each
> > individual service upstream, we are willing to do so, but I'd like
> > some of the init system folks to weigh in with an opinion here too.
>
> > [where init system includes both upstart and the future systemd world]
>
> The Foundations team is responsible for init, both before and after the
> systemd transition. :)
>
> I have a good deal of sympathy for Ted's position that disabling
> *arbitrary*
> services via the custom image is a serious support problem.  I also
> understand that, since we're in early days here, it's not possible to
> comprehensively enumerate the individual services that we need to support
> override interfaces for in order to get the product to market.
>
> So I view upstart overrides in the custom image as an escape hatch, that
> should be used only when all other options to support a more maintainable
> interface have been explored and rejected (possibly because they can't be
> landed in time).  And each individual upstart override that's being applied
> in a custom image should be reviewed (publicly - i.e., here) to make sure
> the team can support it going forward, so that those custom images don't
> find themselves broken unexpectedly due to changes to the underlying
> upstart
> jobs.
>

+1.  We will be sure to only use these when we *have* to, and will work
with relevant upstreams to have better ways to disable them (be those dconf
keys, or android properties, or anything else).  Also +1 to having the
upstart overrides we *do* have to ship being reviewed and documented.


As Ted rightly notes, at some point in the future *all* upstart overrides
> are going to break because we're going to stop using upstart as the system
> init.  And when that happens, the fewer overrides there are in custom
> images
> in the field, the better off we all are.  So Alex, for those places where
> your team is evaluating disabling stock system services, can you please
> work
> with the relevant folks to try to support this a different way?
>

> Upstart support for multiple config dirs is still a useful feature which
> we'll try to implement for you, but if it turns out you don't actually need
> it in practice because the number of overrides needed is zero, so much the
> better.
>

Thanks! We'll try to keep the number of overrides low (hopefully zero) and
will work with relevant upstreams before considering overrides.


> --
> 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
>
> --
> 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
>
>