Skip to content
This repository was archived by the owner on Sep 18, 2020. It is now read-only.

Conversation

@cgwalters
Copy link
Member

I was spending some time investigating how update_engine works, and when first
starting out it took me a little bit to figure out that there were separate
update_engine_client vs update_engine. Having them both in /usr/sbin is
annoying for bash completion.

This is just a minor "papercut"; I'm mostly using this to test running
through the development/contribution process.

I am assuming nothing tries to find these binaries directly and only uses the
systemd service and/or DBus API; I didn't see any obvious hits in repo grep update_engine.

Signed-off-by: Colin Walters walters@verbum.org

I was spending some time investigating how `update_engine` works, and when first
starting out it took me a little bit to figure out that there were separate
`update_engine_client` vs `update_engine`. Having them both in `/usr/sbin` is
annoying for bash completion.

This is just a minor "papercut"; I'm mostly using this to test running
through the development/contribution process.

I am assuming nothing tries to find these binaries directly and only uses the
systemd service and/or DBus API; I didn't see any obvious hits in `repo grep
update_engine`.

Signed-off-by: Colin Walters <walters@verbum.org>
@ajeddeloh
Copy link
Contributor

LGTM, but I worry if this will break anyone who has systemd dropins for update-engine. If they have a dropin overwriting the ExecStart to add additional flags, this will break them. I'm not sure if there's actually users doing that, but it's something to consider.

@cgwalters
Copy link
Member Author

Do you (or anyone) have a sense of whether there are flags that people might want to tweak? update_engine --help doesn't initially look to me like there are any outside of a development scenario but I'm obviously new here 😄

@lucab
Copy link
Contributor

lucab commented Jul 10, 2018

While I think that this papercut is technically ok, I think that at this point in CL lifetime it is not worth pursuing this with the risk of breaking existing customized setups. I'd be inclined to just close this PR.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants