Regarding RPM & DPKG usability
I would like to explain a bit more the 8th point I did on my SLED 10 rant. Here’s the general idea (which can work for both RPM and DPKG):
You create a website that looks like gnomefiles or versiontracker. It should look professional, well done, informative and not like this. You let third party packagers create packages for third party apps and you let them upload them. Upon receiving the RPM file, you check it: 1. With which versions of the OS this RPM would work 2. Does it conflict with other uploaded RPMs or the latest packages of the distributor’s updates. If all is good, you accept the RPM and let the packager fill up some generic information about the software. Then, the software goes live and people can visit its gloryfying web page via the bookrmark in the OS’ web browser. Now, when the user is trying to download the RPM it links to an rpm:// or dpkg:// URL instead. This is a special http type that it’s registered with the OS and its understood that this a package for installation. Immediately a software-installer GUI application comes up, downloads and installs the package for the user. Before it downloads the package, the GUI app checks with the website to see which are its deps and its requirements. If there are missing dependencies, the GUI app checks on the same website to find the extra packages needed and also checks with the OS’ own package database in the DVD (the listing is saved in the installed OS). If the deps are satisfied via extra packages it downloads them and installs them too. If not, then the GUI app bails out, but this should never happen because the website has already checked for these deps when the packager uploaded the RPM.
Additionally, the GUI app should have losen rules about dependencies by default (or its flag should be set per-RPM) so when you have a library that matches closely the required one (e.g. mylib.so.0.5 vs mylib.so.0.3), it lets the package install without a fuss. It shouldn’t bail out just because the lib version is not 100% the same. This allows for many of these packages to be forward installable easier with future distro versions too. The distro must be extra careful to not break compatibility with third party packages for at least 1-2 years (and that’s too little already). Also, the distribution must enable by default on RPM’s creation utility to include the header files of the app that’s getting packaged (usually on an installation of 2.2 GB that’s only an extra 200 MBs of space — and that’s a small price to pay for not get any future headaches). Finally, non-Free software must be allowed to be uploaded in the web site too, simply because the target is to serve the users with tools that they can do their jobs with.
Basically, the idea is a bit like Linspire’s software store, but the workload is on the software community. THAT’S how you create a SOFTWARE PLATFORM and you have your users shut the hell up about “it’s difficult to install apps on linux”. All the distributor must do is create the said web site and engine. I would gladly donate my Gnomefiles.org PHP code to any major distro that would like to implement this (they would only need to write the checking stuff).
The point is to not have “repositories”. At least not in any “user visible” way. The “repository” reality must be HIDDEN from the user. The user must not hunt down ways to find third party repositories and enable them manually and be in the mercy of badly-put-together packages. Neither in the mercy of something like Synaptic. People want to view a website and see what’s new, vote for an app, comment on an app, view screenshots of an app, view statistics of which apps are popular etc. An official web site for third party software with the right checks should deliver all that (plus the feeling of security) instead of using Synaptic and weird repository urls that the user must figure out by himself and trust random webmasters.
And regarding cleaning up the SuSE desktop of 4 different ways of updating the system and 2 more ways of installing new software: only two gui applications are required: 1. The GUI installer that loads when an RPM is clicked/loaded. 2. The uninstaller of RPMs. Regarding the software update daemon it should only run in the background and only flash in the gnome-panel when there are system updates or newer third-party RPM updates available and not a minute before. And when the user chooses to install them, the same GUI installer loads as in #1. A yet another app for “updates” will confuse your users and it is not needed. The daemon will “feed” the GUI installer with the latest updates and flash the gnome-panel, but the GUI installer would just think that it’s just installing some RPMs as it always does. For the user, that’s only two apps to learn how to use and not 6.
Only if the above is satisfied (and a few more things I described on my previous blog post) I would consider a DPKG/RPM distro in my desktops. Until then I will continue to use Arch Linux not because it’s user-friendly (it most certainly isn’t), but because it doesn’t try to be something that is not. It doesn’t try to compete with Windows or OSX, and it doesn’t go after the desktop market. I know what to expect from it and it works perfectly for the kind of functionality it has “promised” me. But when I use FC/SuSE or Ubuntu, I have higher expectations simply because these distros have put themeselves into this position, trying to compete for real-world people’s desktops. If they want to compete in that space, well, they have a lot more work to do than Arch or FreeBSD or Slackware do!