1

I am a user of Debian based distros - Debian, Ubuntu, Linux Mint. I know that often the latest versions of software are not in the repos, so I frequently download them directly from source and install them.

However, I notice that this software rarely lets you know of an update. Also I've never noticed any of them actually updating by themselves and then just asking permission to install.

Is it because it is generally assumed among the coders that the Linux versions will be updated via package manager?

  • Or you could make your own build server that is continually pulling down the latest source and building it. Maybe you could even make your own packages. Then you'll be current. – chicks Apr 8 '17 at 12:45
3

Implementing this type of feature is quite difficult, both the “calling home” side of things (to see if there’s been an update) and the “updating-in-place” side of things:

  • the software running on the user’s system needs to know how to check if a newer version is available (which means adding network code to your application, which might well not have any other reason to use the network);
  • the software needs to work regardless of the network conditions it finds itself in (obviously when it’s entirely offline; but it also shouldn’t fail with strange errors when it finds itself partially connected);
  • you need to have some way of deciding whether a newer version is available (how do you compare versions when users build from the source repository?);
  • you need to have a server somewhere with the server side of things, which you might also need to develop;
  • you need to ensure that updates can’t be compromised, either on the server or through a man-in-the-middle attack (so you need to use TLS and/or strong signing of some sort);
  • you need to make updates available in a form that’s usable by your users; they may have built from source initially, but there’s no guarantee that the system they’re running the software on has whatever is needed to rebuild a newer version from source — so you need to provide binaries (for all possible target platforms?).

(This isn’t an exhaustive list.)

These are all problems that have been handled by distributions, so it’s just easier to let distributions take care of things. In addition, as Kusalananda has explained, users that care about running the latest version of a piece of software probably care enough about it to follow at least an announcement mailing list, so they’ll be notified that way.

Another aspect to consider is that a significant number of people don’t want the software they use to phone home in any way. Some distributions go to some lengths to remove code that does this from the software they distribute, or even other parts of the software that can be used to track its use (e.g. documentation which loads images or fonts or CSS from the web). See all the “privacy-breach” tags in Debian’s Lintian for example.

All this explains why there are so few pieces of software which contain the necessary mechanisms to provide update information themselves, and even fewer which can upgrade themselves.

There are other ways of solving the “problem”: software developers who use a CI system can usually extend that to provide “nightly” builds in a consumable form of some sort (as packages); interested users can set up their own build systems to regularly pull updated source for software they care about (this is fairly common in enterprise contexts); or you can set up AUR-style packages which build themselves from the latest source.

  • On Microsoft's Windows, many applications update themselves. This is because in Microsoft's Windows applications have to implement many things that the operating system has neglected to implement. – ctrl-alt-delor Apr 9 '17 at 11:25
  • @richard indeed. There’s one aspect of Windows that makes this simpler there: you only need to provide two binaries! (And the simplicity of distributing binaries means that fewer users build from source, avoiding some other problems.) – Stephen Kitt Apr 9 '17 at 19:00
  • Same for Gun/Linux: almost all Gnu/Linux use X11, the ABI has not changed for a very long time, and when it does it is backward compatible. That just leaves libraries, these can be statically linked (as done on Microsoft's Windows, if you want to avoid DLL hell). So no different. Therefore it is not an advantage, it is just one of two paths, and the only one travelled by users of Microsoft's Windows, because the other path is blocked for them. – ctrl-alt-delor Apr 10 '17 at 9:13
  • @richard I was thinking of the fact that on Linux, if you want to provide full update coverage, you need to provide binaries for all the possible architectures that users can run Linux on (or at least, the main ones, which can still mean quite a few: i386, amd64, armhf — Debian and Pi variants —, arm64, perhaps ppc64 or ppc64le). And while X11’s ABI hasn’t changed, its environment has, and many clients’ expectations are no longer satisfied — try running old statically linked binaries of proprietary games (CivCTP for example). – Stephen Kitt Apr 10 '17 at 9:21
  • Ah I get you: you are saying that Microsoft's Windows has an advantage, that it will only run on two architectures. This is not an advantage. 2nd I think that Mircosoft's Windows will run on arm and Alpha. Therefore a distributor of software for for Gnu/Linux could just ignore some architectures, and provide source for there. Source code allows us to not leave people/programs behind. For example when the desktop changes, we can recompile (sometimes make code changes), and now we are up to date. On Microsoft's Windows we have several applications from several earas running at the same time. – ctrl-alt-delor Apr 10 '17 at 9:30
3

Unless the software itself has the ability to "call home" to check for updates, like some browsers and things like Syncthing seems to be able to do, there is usually no mechanism that will be able to automatically alert the user/admin that there is a newer version of the software available.

Packages that you install with your package manager are made by humans, users who are likely to have an interest in keeping them up to date and functional on the operating systems that they care about.

Someone who packages e.g. Ansible, or GNU coreutils, or the Yash shell, or CMake or any other of the thousands of software projects out there for a particular Unix system will most likely (but not necessarily) be subscribed to the relevant mailing lists for those projects and/or have special tools for regularly watching source code repositories or source distribution files. When they are made aware of a new release, they will download, compile, test, patch (etc.) and package the software in the relevant ways depending on the packaging procedures on their Unix. This may involve communication both upstream (to the developer of the software) and downstream (to users of the software) about incompatibilities or other issues appearing in the building/packaging process.

Then they will, depending on what Unix they work with and how third-party package distribution works, register, upload or commit the package somehow so that users like me and you can use our package managers to update our systems.

I care, for example, for having GNU Stow available for OpenBSD (I'm the "port maintainer" for this software). I check from time to time what the current status of Stow is on the GNU web site (it isn't updated very often), and when I spot a new version I install it and make sure that it works, and update the OpenBSD port on my private machine. I then email the OpenBSD ports list with a patch for the port (ports are distributed as a set of Makefiles on OpenBSD). Someone with commit rights will then make sure that my patch applies cleanly and that the port looks correct before they commit it to the OpenBSD ports CVS tree.

The next time a user updates the CVS tree and rebuilds the port, or downloads the binary port which eventually will apear, their installation of GNU Stow is updated. But GNU Stow is not in itself aware of whether a new version of itself is available. It's simply not something GNU Stow is supposed to be doing. It's a tool that one uses to install third-party software in self-contained directory hierarchies, and it would be seriously odd if it tried to "call home" every time it was used (as odd as if ls suddenly required network access to run).

To have software update by themselves could in many cases be undesirable as many components of a system needs to be tested together. The needed bits of infrastructure would also seriously bloat smaller packages, and it would be impossible for individuals that lack the knowhow or resources to run some kind of high-availability update server to develop software that keeps itself up to date automagically.

  • 1
    You’re right about watching the mailing lists. We also usually inform upstreams about distribution packages, and as a result some upstreams notify distribution maintainers directly (or even coordinate with them, e.g. to release a new version in time for the next distribution release). We also use tools to check for new releases automatically (e.g. debian/watch in Debian; Fedora has equivalent functionality). – Stephen Kitt Apr 8 '17 at 12:25
2

In the old days, computers were administered by professionals, who would install new software as needed.

Over time, different operating systems evolved two different traditions for relieving the burden of keeping software up to date manually.

  • On Linux and most other modern Unix variants, the operating system comes with a package manager. Most software is installed through this package manager, and the package manager updates software when a new version is available.
  • Windows did not come with a package manager until recently, so providers of Windows software got into the habit of having their own code to install updates.

The package manager approach is especially well suited to the open source world because open source software is composed of thousands of packages that are developed independently and assembled together. A lot of things can go wrong when assembling packages, so most Linux distributions provide a consistent set, called a release. Some distributions have “rolling releases” where the only consistency check is that the software compiles. Others have more testing and only provide a new release once or twice a year, or even once every couple of years.

An advantage of the Linux approach over the Windows approach is that it allows software packages to collaborate with each other. This is difficult in the Windows approach because if software A and software B want to do something together, they have to monitor whether their partner is installed, cope with upgrades, take care not to leave crumbs behind when one is uninstalled… This is in particular why Windows software has to bundle all the libraries that it uses, meaning that if a bug is found in the library then all the software that uses the library needs to be updated. In contrast, on Linux, only the package containing the library needs to be updated, no matter how many programs use it.

Since the operating system provides a mechanism for software updates, authors of Linux software don't need to reinvent the wheel.

There's rarely any need to install more recent versions of software than what your distribution provides. Newer software is in general not less buggy. Distributions do provide updates if a grave bug is found (especially security bugs). A newer version of some software is only useful is that version has a new feature that you have a use for.

If you like to have the latest version of software even when you don't need it, then you should install a rolling release distribution such as Debian unstable or Arch Linux. Distributions with coherent releases such as Ubuntu, Mint or Debian stable are for people who don't want to break their system every week.

1

The other answers are good but I want to add something that none of them prominently addressed: the security issue.

Installing software (at least, installing it system-wide) generally requires root access. You trust your distribution's package manager and the humans who package the software to use this privilege appropriately, but you don't necessarily trust every random piece of software you have installed to do it right.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.