20 things we'd change about installing software in Linux

Let's make Linux software installation less confusing

20 things we d change about installing software

Software installation in Linux can confuse new users, while it pleases and irritates more experienced campaigners in equal measure.

Here are 20 things we'd change about it.

1. Open Source doesn't mean Only Source

"It's open source, here's the source" can be a cop out. Most users don't actually want the source (as long as it's open), they want a binary. Developers should be more proactive about making packages of their programs available. They don't have to do it themselves – there are plenty that would help given some encouragement.

2. How to run

"I've installed Foo, how do I run it?" Hands up anyone who hasn't seen this on a help forum? All window managers that comply with the Freedesktop.org standards, which includes all the main ones, respect the standard XDG desktop files for menu entries. There's no excuse for installing a graphical program and it not appearing in the menus afterwards.

3. Standardised interface

Forget all the arguments about a single package format; it'll never happen. We need a standard package manager interface that'll work with all packages. Imagine Synaptic running on Ubuntu and Fedora, and knowing whether to use RPMs or Debs.

4. Easier adding of repositories

Adding repositories usually involves copying and pasting long, arcane text strings from a web browser into a terminal. A standard filetype for a repository addition file would enable the browser to launch the appropriate package manager to add to the repository – after the usual "are you sure/do you trust this" dialog.

5. Easier source building

How many programs don't even have specific compilation and installation instructions? Many just have the generic Autotools text. If it's that easy, why not include an install.sh script that does it for the user? Even better, have it check for dependencies properly.

6. Autotools = yuck

Please can we move into the 21st century with this? Autotools is slow and cryptic. It was intended for use by developers, and end users should not have to be exposed to this sort of thing if they want to install something not available as a binary.

7. Reduce filesystem splatter

Is it really necessary to install files in countless directories? It's not so bad when installing from a package manager, as it knows what to clean up when uninstalling. Source builds, however, can be a nightmare to remove from the system, especially when developers don't provide a make uninstall target.

8. Standard metapackage

If we can't agree on a single package format (and we never will; even if we did, someone would come up with a new one), how about a standard package container file? In a similar way to how an AVI file can contain various types of data, a metapackage format could hold RPM, Deb or Slackware TGZ information, or any combination of two or three, allowing the same package to work on multiple distros while still respecting the different systems.

9. Standardise package names

Why do different distros give the same package different names? Resolving dependencies for source packages would be a lot easier if there were consistent naming between distros, enabling build scripts to state "you need to install libfoo", or even offer to do it for you.

10. Standardise package splits

It's not just package naming that needs some consistency, the way projects are split into sub-packages by each distro is also inconsistent. Strong direction from the upstream developers would go a long way to giving consistency and reducing confusion.

11. Get rid of -dev package hell

The -dev or -devel packages containing library headers cause no end of confusion when trying to compile source, such as "libfoo not found" messages when it is clearly there. A switch to automatically install associated -dev packages, turned on when you install GCC or Autotools, would save a lot of grief at the cost of a tiny amount of disk space.

12. Automatic installation of source packages

If a different package is needed for each distro, maybe a single source package would cover all the edge cases, but only if package managers had the ability to download, compile and install the source for you. Current source package installation isn't much more than dumping the source code on to your hard drive.

13. Browser-based package management

Package manager GUIs are pretty good now, but remote installation requires dropping back to the command line, with all its pros and cons. A package manager that ran in a web browser would make browsing and updating software on a remote computer so much more pleasant.

14. Do we need so many packages?

Some projects have the source, along with Deb and RPM files, for download. Others have separate packages for every version of Ubuntu since brown was invented, plus every SUSE and Fedora variant. Is that really necessary, or is it just easier for the developer and to hell with the poor end user (or our poor disc editor Mike)?

15. No single directory installs

The idea of installing each package in its own directory comes up from time to time. While it appears to have appeal, it's inefficient and adds more problems than it pretends to fix. If you had all-encompassing package management that took care of all details of installation for us, it wouldn't matter where files were installed – just click the install button then run the program from the menu.

16. Link to package manager from web pages

web based package manager

When you find a website for a package you want to try, you then have to start looking for the package in your package manager, or risk using one direct from the site that hasn't been verified by your distro. A type of URL that launches the package manager to search for the package, like market:// URLs do in Android, would make it so much easier to go straight from the website to installation without the various risks associated with Windows-style EXE installers.

17. Run after installation

If you're installing a piece of software that isn't a background process, there's a good chance that you want to actually run it as well as install it. How convenient would it be if your favourite package manager had a checkbox to run the program after installation? There'd be no hunting through menus after installation, just hit 'Install and run' and that's it.

18. Keep source builds in package database

Not only is installing from source a bit of a pain, it also means that the package manager is unaware of what you've installed, so it thinks that dependencies aren't satisfied. Having a package manager that could also build source packages would not only ease the pain of installation, it would also enable it to keep track of just what is installed on the system.

19. No all-inclusive packages

The separation of applications and libraries into separate packages introduces dependencies and other problems, but these are handled efficiently by most package managers. The alternative, as used by Windows, is to put everything in one package, meaning you can end up with different versions of the same library scattered across your filesystem.

20. Clean up old dependencies

When you install a package its dependencies are also installed, but when you later remove the package those dependencies stay on the system, gradually filling up your filesystem with cruft. Not only should package managers remove dependencies that are no longer required, they should be able to check and clean up the system from time to time as well.

Article continues below