Allow apt updates to be automatically installed

[lewisgoddard]

Right now whenever I log on I am pinged about a few minor updates, that rarely require a restart. Why not just install them whenever there's reliable network?

Suggested options:

• Don't auto-install any updates. [Not recommended]
• Auto-install only Security updates. [Default]
• Auto-install all updates.

We should never auto-install driver updates or anything that removes packages marked as installed (as opposed to dependencies, which we can safely remove).

[cassidyjames]

Just have to be exceedingly careful about updates that are potentially breaking updates since we don't have a rollback mechanism for the OS.

[lewisgoddard]

I guess that this shouldn't include stuff that appears in the drivers section, or the big kernel upgrades that come with new stacks. Apart from that, auto-installing isn't much different from prompting the user every time they log on.

[cassidyjames]

Since this seems to be talking about apt updates, I'm going to clarify it around that and open a new issue for Flatpak automatic updates.

[davidmhewitt]

I think the easiest way to do this technically would be to make use of the packagekit offline updates flow. If automatic updates are enabled, download them in the background (if not on a metered connection) and then schedule them to be installed on the next shutdown or reboot.

We could probably add an option to the shutdown dialog to skip installing them on that particular shutdown reboot if someone wanted to shutdown/reboot fast for whatever reason.

[marbetschar]

@davidmhewitt does this also work with hibernation? Personally I rarely ever restart my Laptop - but as for "automatic updates" I'd expect updates to be installed without user interaction most of the time aka. without the need of a restart. If a restart is needed, I'd expected to be explicitly prompted.

[davidmhewitt]

I doubt it works with hibernation.

A lot of apt updates require a reboot (or at least a restart of the programs/daemons contained within), and we have no programattic way of determining which ones require that. Sure, we could guess and make a list of things that almost certainly need a reboot like the kernel, systemd, etc... but there would always be something we missed.

That said, according to this issue report, we don't want to automatically update potentially breaking packages automatically anyway. So maybe what I'm saying is irrelevant if we're only suggesting to update "apps" automatically.

However, I'm advocating offline upgrades as a safe, tested way of doing this. They run while the OS is shutting down with an explicit "packages are updating, don't turn off your system" message, so it's clear what's happening. If we just let AppCenter do them in the background, I can see people going, "Why is AppCenter consuming CPU in the background?!" and killing it, then they're left with broken packages.

Offline upgrades are used as standard in Fedora/GNOME software and seem to work reasonably well.

It's also quite difficult to implement logic for dealing with dependencies on top of PackageKit, so even if we decide that we only want to update apps (like this issue report suggests), those apps that we want to update might pull in updated dependencies for system components, that pull in updated drivers, that pull in an updated kernel, so I think it's possibly an unrealistic goal to suggest that we'd be able to say with 100% certainty that we won't update "dangerous" packages with "automatic updates" whether they're offline or online.

[internetman420]

Please implement this. It is actually one thing that is for the time being making me not suggesting EOS to less tech-savvy friends because I foresee that the constant small updates notifications will annoy the h**l out of them :/

[danirabbit]

I'm going to transfer this to settings daemon since we've been talking about doing offline updates there