Linked by Eugenia Loli-Queru on Thu 22nd Feb 2007 23:24 UTC, submitted by Andrzej Ptak
Linux There are currently at least five popular ways of installing software in GNU/Linux. None of them are widely accepted throughout the popular distributions. This situation is not a problem for experienced users - they can make decisions for themselves. However, for a newcomer in the GNU/Linux world, installing new software is always pretty confusing. The article tries to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux.
Thread beginning with comment 215691
To read all comments associated with this story, please click here.
Some Goes To Download FireFox...
by Rlwimi on Fri 23rd Feb 2007 00:18 UTC
Rlwimi
Member since:
2006-11-02

Someone sees an announcement on a news page that version x.2 of FireFox just was released and they want to install it.

On OS X you click on the link to the new version and either you get a disk image or an archive of the app. Double clicking either unpacks the app or mounts the disk image. Both ways the app is ready to run. The user can drag the app to anywhere they want and OS X automatically makes note of file types and other such app related issues automatically. Prefs go right in the common user pref directory. Deleting the app involves dragging it to the trash can. Most apps have all its resources tiddley packed in the .app bundle folder so when the app is moved or deleted nothing is left behind.

Windows usually has an installer/unistaller for apps. Corruption of the registry can lead to problems. And apps need to be re-installed if you re-install your system. Not as flexible and tidy as OS X's bundles but you also don't have to worry about apps leaving extra files around on the harddrive.

Linux...

You have to know about adding repository urls to your package management utility.

You have to wait around for someone to manually add new apps to the database.

You can be faced with your current repositories not having the app you are interested in.

Other than packages are the way it's always been done with Linux, what practical benefit does an average desktop user get from downloading a common user app like FireFox from a repository and having it wrapped in one of the many different Linux package types?

Since the FireFox can run on Fedora, Ubuntu, Gentoo, etc the differences between the systems can't be that drastic. Is just each of these distros can't agree where to place various app and config files? And if these differences are important enough to keep that you require a package format to handle the differences what benefit are Linux users getting from this disparity?

SlackerJack Member since:
2005-11-12

You can download Firefox and run it from it's own directory in Linux if need be. The benefits of waiting for it to appear in your package manager is knowing it's gone through another layer of testing.

Reply Parent Bookmark Score: 5

antenna Member since:
2006-10-22

Yep, as well as drastically reducing the chances of running malware on your machine, the fact that it will install with no immediate setup required (no desktop icon nonsense), the fact that you can supply it as an argument on the command line with 500 other programs that will all work the same way, the fact you'll be able to trace what files on your system are installed by which particular program, the fact you can uninstall 1000 applications cleanly at once, the fact you can update all your software and system at once, the fact you can keep a single shared library updated with ease and save on resources... I really could go on.

Reply Parent Bookmark Score: 5

Jake Member since:
2006-01-08

Other than packages are the way it's always been done with Linux, what practical benefit does an average desktop user get from downloading a common user app like FireFox from a repository and having it wrapped in one of the many different Linux package types?

The benefit doesn't come from downloading a common user app like Firefox, it comes from dowloading, installing or upgrading, and configuring nearly any common app like Firefox, plus the uncommon ones, plus the core operating system, typically in only one or two steps. If you don't want to upgrade everything, you have that option too.

People complain about package management in Linux, but I prefer any package manager to the Windows model of:
1. look up the app on a third party site to find out if it has spyware/adware/etc.
2. download from the distributor and click next a bunch of times to install
3. waste space with redundant copies of incompatible versions of libraries
4. rely on the app to notify you of updates and clean up after itself on uninstall

Reply Parent Bookmark Score: 2

Joe User Member since:
2005-06-29

1. look up the app on a third party site to find out if it has spyware/adware/etc.

This is FUD, and it's just not true. I have never downloaded spyware from Adobe or Skype web sites. To tell you the truth, I have never downloaded spyware/adware from any software vendor.

2. download from the distributor and click next a bunch of times to install

This is handy to set your configurations (place to install, install for one or all users, start together with system bootup, readme file, language support choice, etc...). Neat flexibility that Linux doesn't give during installation.

3. waste space with redundant copies of incompatible versions of libraries

This is hardly true, maybe a few KBs, and this definitely doesn't make any difference in today's 500GiB drives.

4. rely on the app to notify you of updates and clean up after itself on uninstall

Fine, but Linux applications don't uninstall everything either, so...

Reply Parent Bookmark Score: 4

wannabe geek Member since:
2006-09-27

Well, IMHO, I think you guys are comparing apples to oranges. Centralised repositories of open source packages are GREAT (more convenient, easier to automate, much safer...). The problem is what to do when you want a program and it's NOT in the repos. If you are using a mainstream distro, chances are that there's an unofficial repo you can add to your "sources.list". This is not an ideal solution, since name clashes and similar problems are rather frequent. If your distro is not so mainstream, then you need an installer (not so frequently found), or you have to compile from source. Among other problems, these methods are more likely to wreck your system, and the apps are not integrated with the applications from the repos.
So, an ideal package management system should let you install programs on your own, and keep track of which programs are from the repos and which ones are from outside, make them work with each other and with the DE and unistall them cleanly. And it has to manage shared libraries if it's going to be used extensively.

Reply Parent Bookmark Score: 3

MamiyaOtaru Member since:
2005-11-11

Someone sees an announcement on a news page that version x.2 of FireFox just was released and they want to install it.

what practical benefit does an average desktop user get from downloading a common user app like FireFox from a repository and having it wrapped in one of the many different Linux package types?

The benefit is that they don't have to "(see) an announcement on a news page" for Firefox, or x number of other apps they may have installed. apt-get upgrade will install it for them, along with any new versions of any other program they may have. They don't have to hunt around news pages for each bit of software, but can open up their package manager and see which apps have new versions and choose which ones to install, all at one go.

If the software is available only from the app vendor's own repository, adding the repo is a bit more work than doubleclicking an exe (after finding and downloading it) but once the repo is added, it's there. One doesn't have to add it again for the next new version.

It's just a different way of using it, with obvious advantages. People who really don't like it have other options, like OSX and Windows. Maybe people should stick with those instead of pestering Linux distros to change their time honed methods of installing and keeping up to date the many apps people use.

Reply Parent Bookmark Score: 3

butters Member since:
2005-07-08

Someone sees an announcement on a news page that version x.2 of FireFox just was released and they want to install it.

Any kind of user that reads news sites that post about new Firefox releases will have no problem going to mozilla.com and grabbing the standalone tarball (by clicking on the big green "download firefox" button). Your DE will automatically open the tarball in the archive application. There's a script in there conveniently called "firefox" that starts the browser. All of the settings and whatnot are stored in this folder, and removing the folder removes the app. It's a quick and dirty solution. Very much like how all software is installed on MacOSX.

You have to know about adding repository urls to your package management utility.

Only when you're updating to new releases of your Linux distribution, which is much easier (and cheaper) than doing so on MacOSX.

You have to wait around for someone to manually add new apps to the database.

On MacOSX you also have to wait for somebody to package the software for you. Except that on Linux there's almost always a way to build it yourself if you know how, which is almost always impossible on MacOSX.

You can be faced with your current repositories not having the app you are interested in.

New Mac users often find themselves in the same situation--not being able to find the kinds of software they used to use on Windows. Old Mac users prefer to live in a world where you never need software that isn't readily available for MacOSX, which is similar to the way old-school Linux users think. I don't have a single package on my system that wasn't installed through my package manager. Heck, most Linux distributions come with 90% of the software you'll ever need right out of the box.

what practical benefit does an average desktop user get from downloading a common user app like FireFox from a repository and having it wrapped in one of the many different Linux package types?

Benefits include adding Firefox to the applications menu, placing the binary in a directory that's already in your PATH, allowing all applications that use the Gecko renderer or XUL toolkit to use the same version, allowing all users on the system to run Firefox, placing the documentation in a known place where your DE's help functionality can find it, enabling your distributor to specify defaults (including themes) that are consistent the rest of your desktop, keeping you aware of available updates (which Firefox does on its own but most other apps don't), and providing a single interface for installing any application. There might even be more benefits, but that's enough for now.

Since the FireFox can run on Fedora, Ubuntu, Gentoo, etc the differences between the systems can't be that drastic.

Firefox also runs on Windows and MacOSX, so they must not be drastically different either...

Is just each of these distros can't agree where to place various app and config files?

No, binaries go in /usr/bin on nearly every distribution (except for GoboLinux and some other weirdos) and config files go in ~/.appname for each user, or /etc for system-wide configs. It's all very standardized from distro to distro.

The reason why each distribution maintains their own repositories is so that they can ensure that all of the packages work together seamlessly. The reason why they need to ensure this is because each distro includes earlier or later versions of packages depending on when they were released and includes (or excludes) different packages depending on the requirements of their userbase.

if these differences are important enough to keep that you require a package format to handle the differences what benefit are Linux users getting from this disparity?

The differences don't mandate different package formats, they mandate separate package repositories (as explained above). Since one distro's repositories don't work with another, it doesn't matter which package format they choose. There are plenty of RPM distributions with different repositories that don't work together. The RPMs are all in the same format, but one distro's RPMs won't work on another's. Same with DEBs, although there's slightly more unification on that side of the universe.

The ultimate benefit is that we aren't locked into one distributor with one idea of how a Linux distribution should be managed, developed, tested, and released--as well as how free (libre) it should be, what kind of user it should target, what kinds of machines should it run on, what support options should be available, which desktop environment should be the default (if any), and other matters of taste and requirements. The benefit we get is choice and along with it the high probability that at least one of the distros is right for me, possibly right out of the box. We also get progress, since small distros can try out new ideas that eventually make it into the big ones, and each distribution benefits from the unique insights of the others.

If we really had this thing nailed down--exactly how to build an operating system that everybody likes--then we would standardize. But we refuse to settle for merely "good enough" like some other OS vendors. We honestly want to get this right, and in order to do this we need to try different things and see what works (and what doesn't). Sharing enables us to take advantage of the benefits of diversity without a large penalty in the overall productivity of the community as a whole.

The fact of the matter is that we aren't seeing a proliferation of new major distributions. That era has past. Instead we are seeing the community come together behind a few projects, and distributions begin to derive from these projects. Just look at all of the consolidation that has happened around Ubuntu within the past 18 months. The Linux ecosystem is taking form as a three-horse race, and that seems like a manageable number for proprietary ISVs to target. The community has proven that it can take care of packaging the OSS stuff itself.

Reply Parent Bookmark Score: 5

Snifflez Member since:
2005-11-15

I'm afraid, you're generalizing a bit too much here.

"You have to know about adding repository urls to your package management utility."

Nope, I don't have to do any such thing. When the software becomes available, I will be able to get it simply by telling my package manager to install it. Could you be more specific as to which distro you're referring to?

"You have to wait around for someone to manually add new apps to the database."

Not really. All _I_ have to wait for is for the package to marked as stable, which I don't mind waiting for at all, since I'm not a big fan of running poorly tested software on any of my machines.

"You can be faced with your current repositories not having the app you are interested in."

Once again, not really. If this piece of software is something I need, I can just compile it from the source, which is not as scary as some people sometimes think. Otherwise, like I said, I can wait. Or, I can compile it and help test it if I'd like to speed up the process.

"Other than packages are the way it's always been done with Linux, what practical benefit does an average desktop user get from downloading a common user app like FireFox from a repository and having it wrapped in one of the many different Linux package types?"

Say, tomorrow all Linux-based distro developers get together and decide that they're going to adopt a Mac OS-like way of installing software on their distros -- you know, the process you've described. No more packaging software fragmentation. What's going to happen?

For the sake of the argument, let's assume that "average user" is someone who just wants to install Linux and use it without ever having to worry about things like conditional compilation, optimizations, etc. What about the power users? What about those not-so-power users (myself included) who want to have a higher degree of control of what gets installed on their systems and what doesn't? I mean, the system you've described sounds awesome, but I _personally_ would find it extremely limiting.

Allow me to illustrate. Say, I want to install Xine media player. So, using your system, how should Xine be built? Should it include support for DVD, MP3, ALSA, DirectFB, OggVorbis? Who's going to decide? What if I don't have any .ogg files and I don't plan to use ALSA, because I actually prefer the OSS compatibility layer in the kernel? Why should I have installed capabilities that I won't ever use? Doesn't it limit _my_ freedom to decide what goes on my computer and what doesn't (beyond the packages needed to resolve the dependencies, that is)?

You may say, Well, dude, if you're so picky, then download the source and compile it yourself. Sure, and if push came to shove, I could do that. No problem. And I wouldn't be alone. Soon there would be hordes of anal nit-pickers like myself and power users compiling their own software from the source. But, you see, they would have to resolve dependencies by hand in this case, which is a bit of a pain in the butt, so before you know it, someone would come up with a set of scripts to automate it and -- voila! -- behold a new package manager. Back to packaging software fragmentation.

Personally, I believe that the general fragmentation present in today's Linux-based systems (a multitude of package managers, desktop environments, media players, web browsers, etc.) exists because of two factors:

1). The very nature of open source: freedom to modify the source code. If someone capable of coding doesn't like where a particular project is heading, (s)he is free to either fork it or write a clone.

2). Users. In other words, if users didn't want to use GNOME, its development would have stopped a long time ago.

"Since the FireFox can run on Fedora, Ubuntu, Gentoo, etc the differences between the systems can't be that drastic. Is just each of these distros can't agree where to place various app and config files? And if these differences are important enough to keep that you require a package format to handle the differences what benefit are Linux users getting from this disparity?"

Methinks that the flawed assumption here is that "Linux users" are some kind of a homogenous group. They aren't. Maybe they can't even be homogenous.

Reply Parent Bookmark Score: 2