First, some background. I am working on a new version of a product that will be adding a Linux version, consisting essentially of a daemon. The version of this product for other platforms will support periodic automatic updates, and we want to do this for the Linux version as well if possible. The product is intended for servers and not workstations/desktops and will be a mostly set-it-and-forget-it daemon that is configured ahead of time or via a remote console.

The idiomatic way to distribute software on Linux is via the distro's native package manager or by compiling it directly, but as far as I can tell it is also part of the culture for the packages to only be upgraded manually to leave the user in control.

We have two general groups of users: group A with large deployments that we assume will have access to management tools and fleet management that will be able to automatically run package manager upgrades, and group B with a single or a handful of servers that are mostly manually managed. We figure some among group B will want to opt into autoupdate functionality if available, and that group A will not want it to interfere with their automated solutions.

Taking Ubuntu as an example, is there a solution for automatically updating the package that is available, acceptable for most Linux administrators and reliable? Technically, automatically running apt-get --only-upgrade install acme would do the trick, but previous answers verify my theory that it isn't considered acceptable for most Linux administrators for programs to initiate this by themselves.

In many cases, there will not be a local user logged in and monitoring the server that we can ask (we think a significant number of users will not even have the GUI installed or enabled), so I don't think "ask, then kick off autoupdate when they agree" is a solution that will address everyone.

Are there other options I should be looking into and/or a package that already does this in a great way?

(I have a hunch that the actual answer could be "if group B wants this functionality, let them install the solutions group A is using, otherwise let them update manually; don't offer any functionality at all". This question is to make sure we are not missing any options that would make both group A and group B happy and still be a good fit with package management, Linux and the distribution's own cultures.)

  • It is trivial to enable automated updates (and some distros this is the default). Commented Feb 2, 2020 at 12:19

2 Answers 2


...as far as I can tell it is also part of the culture for the packages to only be upgraded manually to leave the user in control.

Yes! That is correct.

Is it considered acceptable for most Linux administrators for programs to [run apt-get --only-upgrade install acme] by themselves?

This is entering opinion territory, but I say it's absolutely not acceptable. In short, people have different use cases for how they use Linux. For some, automatic updates would be desirable. But for the poweruser, say someone who's in the middle of an audio recording session, automatically consuming resources in the background would not be acceptable.

An alternative is to have your application check for updates (for itself only, not the entire OS) and notify the user. Skype and syncthing are examples of this.

  • The software is mostly meant for servers and it's an unobtrusive and headless daemon, so there are few ways to notify the user and few users will be actively looking. I'm guessing that the users who will most appreciate autoupdate are the users who have many servers, and who will probably not log in to a single server to answer to those notifications. Is it better to assume that these users will have some software that can keep track of package versions across entire fleets of servers?
    – Jesper
    Commented Jan 23, 2020 at 13:49
  • @Jesper I'd suggest you to edit these details into your question (product mostly for servers, possibly many of them, likely in environments in which it'd be reasonable to assume configuration management software was present), they seem relevant.
    – fra-san
    Commented Jan 23, 2020 at 14:06
  • @fra-san Thanks for pointing that out - I added that to the question. Not everyone will have that sort of software, but some will, and we want to find something that works well for both people with one server and many more, and that also works in a way that makes sense to Linux and the distribution.
    – Jesper
    Commented Jan 23, 2020 at 14:28

You can create a deb (you may also need rpm and the one for suse etc.), then create a package repo. Have your users add the repo to there config, and install the App. It will then be managed with all the other software.

Here are a few vendors/apps that do this (all of these are available in the default repos (but upstream provide newer versions):

  • Google/chrome
  • Oracle/VirtualBox
  • Docker/Docker
  • This explains how to create a package, which I'm already doing. When you say "managed", are you referring to anything aside from the user running apt or a frontend and updating manually?
    – Jesper
    Commented Feb 3, 2020 at 11:18
  • I mean whatever they use to manage packages. For example apt (but only an example). Commented Feb 4, 2020 at 21:21
  • Yes, that sounds like how packages work in general. The question was: which is the best way, if any, including technical and cultural factors like "will it work everywhere", "is it a good idea in general" and "will people be accepting of this functionality", to invoke automatic updating for a package. All of the examples have been desktop programs where a user can be expected to directly interact with it, which is not applicable to my scenario, so I'm thinking it's probably better to not do anything specific about it and let people update the package themselves.
    – Jesper
    Commented Feb 5, 2020 at 9:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .