Ever since getting into Linux, the one area that has bugged me as weak, compared to MS Windows, is installing, updating, and removing packages.

Every distro has its own tools, and over the years the toolset has only gotten bigger (rpm, yum, up2date, smart, urpm, yast, and now SuSE's latest mix of 3 technologies just to install updates).

I have always guessed that distributions not following the same file system hierarchy or same installation location, is one of the leading causes of distro-specific program installation.

So, what does it take to make a distro neutral package? Just a simple rpm that could be installed and WORK in ANY linux distribution.

While we all have documentation on rpm in our linux distro, I wouldn't use it to try and remove something that was installed by Yast, for example. I'm not confident it would uninstall correctly or break who knows what.

Linux hardware support has improved dramatically. But as more and more distros appear on the horizon, installing, updating, and removing software has only gotten messier, more complicated, and unreliable. This tide needs to turn and get easier and more stable.

What exactly is involved in making an app distributable? (A brief outline is all I'm asking for here.)

Installing Linux is relatively easy, but maintaining a "current version" (such as the latest OpenOffice when your distro doesn't provide it) is not even possible with most distros, without adding repositories, if you're lucky to find them. And then you end up with sources from your distro and 3rd parties, which can really muck up your installation in a hurry, even if you're careful. If there are no repositories, then what?

Linux needs some uniformity and and simpler methods that everyone will agree on. BSD only uses a few ways of installing software, and compared to Linux, BSD makes it simple. But BSD lacks the hardware support. So, Linux distributors, K.I.S.S. please!!

I tried SuSE years ago because of Yast--and it was great as long as it worked. But when I wanted more up-to-date software that's when I discovered what a real pain it can be. And when SuSE broke, Yast was of little help. When updating KDE breaks GNOME, or vice versa, then something is really wrong with the whole update process.

Another example. Users shouldn't have to compile binaries just to get the latest Yahoo! Messenger installed. And they shouldn't have to have RedHat or Debian because that's all that YIM is available for.

The bottomline is that Windows STILL (after all these years) has Linux beat when it comes to installing and removing software. Come on distributors and project leaders. Some cooperation and standards are badly needed in this area.

Remember how bad installing and removing software was on Windows before MS got smart and drafted a standard?? That's what Linux needs and it's long overdue!!

Let's give Bill a real hard run for his money while he uses his bullying tactics of patent threats. Let's be more innovative than Windows guys and gals.

Thanks for listening and please share your feedback.

JohnE1

http://autopackage.org/ and http://klik.atekon.de/ may be what you mean. But package management for individual distros have all come a long way and the days when only Debian could boast of thousands and thousands of apps being a few clicks away are now on the way out.

I believe it has something to do with the repository-based approach with most Linux distributions. While it has its weaknesses (as you have mentioned), it has its strengths too. eg. you can install the gimp with just a "apt-get install gimp" or the equivalent for other package managers (and the package manager takes care of the dependencies, too). To the best of my knowledge, that is not possible in Windows or other OS's using the Windows approach of managing softwares.

To Xavier, thanks for responding and jumping into the dialogue.

Autopackage may be on the right track, but it's not there yet, as they readily admit. At least they're making an effort to address the very issue I'm raising.

I have wondered for the past 2 years why the Linux Standard Base (LSB) does not include package management. I believe it should. Then no one distro would have more apps available than another. While technically, Linux is only the kernel, without the apps we wouldn't need the kernel, so the LSB should have an inherent interest in what makes up the rest of a distribution.

Your mention of Debian's advantage of a few years ago just reinforces my point. The problem wasn't lack of applications for Linux.

The real problem was the lack of a simple and reliable way to install those applications (ELF binaries) into ANY linux distribution. Why should the source code need to be recompiled for Mandrake vs. SuSE vs. RedHat, etc.?? An ELF binary is an ELF binary. The dependencies shouldn't vary from distribution to distribution. If every distro is recompiling the same source code just to end up with the same binaries, then that is a LOT of redundancy and wasted time, in my opinion.

JohnE1

In my opinion, the complexity is the price we have to pay for the customizability. For instance, compiling from source code offers many customizations. Clearly an apache binary for a household router should not be compiled with the same configure options (features) as a binary for a mainframe server that requires many more features? I believe that is one of the reasons why the unified approach you mentioned would not work. For example, a distribution that targets power users may prefer a version of KDE or GNOME with features that only power users will need, such as database connectivity, while a user-friendliness oriented distribution like Fedora or Ubuntu may want to include more convenience oriented features (as you can see, I am bad at giving good examples, but that is what I mean). Therefore
is not entirely true.

As a result, there will be the varying dependency between distributions problem you mentioned. Eg. libssl is only needed by apache binaries compiled with SSL support.

Of course, there is always the option of including everything that is potentially needed, but then we will probably end up with something like Windows Vista that takes up 6GB of harddrive on a fresh install with nothing much really (OSX is not much better if not worse in this aspect either)

I believe that's what differentiates Linux from convenience oriented OS's like Windows and MacOS.

To cyberfishee, thanks for responding and jumping into the dialogue.

Yes, apt is a very nice and simple installer. Wouldn't it be nice if you and I could just apt-get any Linux appliction into the distribution we're running, be forewarned of missing dependencies, have it offer to install those missing dependencies, and then keep on rollin' along.

That's how it should be, but instead every distro is using it's own installer tools, leaving us stuck in our own "proprietary" distribution. In my previous post I forgot to mention apt and swarenet, apt being designed for Debian users and swarenet for Slackware users.

Is there any greater issue preventing you from strongly urging all your friends to switch from Windows to Linux than the issue of how they will maintain the packages? Obviously, the vendors feel it's a huge issue, cause they've all come up with their own way of maintaining packages, complete with redundant (yet proprietary) mirrors and proprietary repositories.

We need less, not more, package managers. Come on, to those that decide on the Linux Standard Base(LSB). Help the Linux desktop standardize and gain some very valuable uniformity. Decide on a "standard" package manager, complete with guidelines for how that package manager should deal with dependencies, where apps should be installed--bins in 1 place, maybe libs in another, .h in another, etc.--and some kind of standard uniform file hierarchy beyond what you already have for the kernel.

JohnE1

You raise a very good point, cyberfishee, compile-time options. Hmmmmmm... damn if you haven't stumped me on that one. LOL

But commitee's like those that decide on the Linux Standard Base(LSB) have dealt with equally difficult questions and came up with standards that worked. ;-)

As for the bloated install from every compile-time option being included, isn't that exactly what a lot of distros are doing right now with the kernel? Compiling in all kinds of options you and I will never use, but just in case, they're in there.

With the huge hard drives we have today, space is not near as much a concern as speed/performance.

JohnE1

Windows-get does this under Windows.

Repository-based installation has it's uses, but it is rather limited. The biggest limitation is that it only allows users to install the particular packages and the particular versions that happen to be in the repository. Users still need other means to install packages that are not in the repository.

I believe the diversity in package managers is also due to the diverse nature of Linux. Package managers are not made equal, some emphasizes on the customizability (Gentoo's emerge), some on efficiency (Debian's apt-get), and some on convenience/user-friendliness (Redhat/Fedora's YUM) (btw, I this is the first time that I have heard of swarenet, so apparently not famaliar with it). I believe they each have their uses. Eg. can you imagine telling a Linux newbie to use emerge or telling a professional Linux administrator to use Yum? =P

Yes indeed, they are very capable at problem solving. However, please keep in mind that Windows and Mac developers have been trying to solve this problem on their respective platforms for more than 15 years without much success =).

Currently, what they do is either bundling a copy of all the libraries they use with their applications, which, besides the space inefficiency, also makes it hard to upgrade libraries globally, or they tell their users to download and install the libraries they require separately, which is a lot more work.

To that point I completely agree, that is what I have been wondering for a long time, too.

Thanks for pointing it out, I wasn't aware of it.

I hold an opposite opinion on that matter, the repository system is one of things I like the most about Linux. Besides solving the dependency issue, it allows users to keep their systems generally up to date(not necessarily the cutting edge version) easily, provided that a well-maintained repository is used. And in the case of Debian (not sure about other distributions), there are even three or four stability/updatedness levels to choose from. Also, it is very possible to install packages not in the repository by other means. Eg. alien can be used on debian based distro's to install rpms, there is a port of APT for Redhat based Linuxes, and almost every distribution with gcc and friends can use tarballs.

Opposite to what opinion?

It is a fact that repository-based installation is limited to installing the particular packages that are in the repository! It is also a fact that installing anything that is not in the repository requires the use of another installation method.

Not exactly, well not in my experience. The package management app i use (pacman) is repo based and can install from repos as standard. But it can also be used to easily add a local package, obtained from anywhere, providing you can meet its dependencies. So in theory you could dig up an old package online somewhere and install it, i don't call that limited. RPM can also install a package obtained elsewhere.

It's other benefit is AUR (Arch user repository) whereby people maintain PKGBUILD files, that combined with source are turned into installable packages for that system.

Maybe if there was a way to auto generate a PKGBUILD from your system, against the source, then you could create and installable package from anything. Effectively having a universal packaging system.

My understanding of the AUR system is VERY primitive, and probably isn't nearly as simple as i think .

to this:
Yes, of course that is true. What ethics and I are trying to point out is that, repository-based installation is not the only way to install packages on Linux distributions.

I am not famaliar with Arch Linux and hence the AUR at all. From your post, it seems to me pretty similar to Gentoo's Portage system (both use source-based packages), which I have some experience with.

its just not possible for every linux binary to run on any linux system.
if concern is keeping the system up to date then repository apt type clones are the way to go.
if you think its "limiting" you arived on the sceen after they already existed.
old rpm based distributions had no way to upgrade anythin which is why they all adopted debian type systems which sort of now is an actual standard.
it seems like in the original post you propose going back to prm as the package tool.
Oh man -- those old rpm only distributions were horrible and rpm itself is a very useless tool.

you also can't come up with any kind of standard for compile options and patches that could be universal for more than a few seconds. The entire situation is 100% fluid and changing constantly.
building a linux system is a fluid and changing thing. I think you are really missing the fundamental differences in distributions. It goes way beyond filesystem placement and package tools.

it seems so easy to add applications to existing distrbutions or change the way some things are compiled or whatever.

diversity is a good thing. If we were left with just one rpm based distribution "standard" i would either compile the entire system myself or stop using linux.

I actually like rpm because its very flexible and has a multitude of options available if you know how to use it. One thing that I have noticed (particularly from Debian users) is that some people compare rpm to apt instead of comparing rpm to dpkg. Apt should really be compared to something like yum, urpmi or smart because it does a similar job and they have more or less the same features.

There are different advantages and disadvantages to the various mechanisms of installing software in Linux. What we really need isn't a standard mechanism of installing software, but a standard USER INTERFACE.

What's needed is a meta-package file type, which in its minimal form is a tiny text file with nothing but a package name. It can also optionally include package names specific to package management systems and/or specific to OS. It can even include a a source tarball.

The user can simply click on this file, or a web page link to this file, and the OS's package management system will take care of the rest. A user of Gentoo or FreeBSD may be presented with a popup window with various compile options. A user of a mixed Debian Testing/Unstable may be presented with options for which branch to install from.

For average users, this means that you get simple single click installation of a program--he doesn't have to even know what OS he's running. Power users can keep all of the features of their favorite OS's package managements systems.