OSNews

Most 3rd party apps are that way. They are just an installer or script, or even tarball, that you unpack somewhere, or that goes into /opt and that's it. No scattering of files across the file system or anything like that.

What is needed is not to get rid of existing package managers, but have two types of package managers. One type is for the base system and the other is for 3rd party stuff. The latter could be standard and would basically manage installing into /opt or something like that, with a nice GUI front-end, so software can be easily installed from websites, CDs, etc.

The existing package managers should remain because they solve the problem of modularity in the Linux base system and they do it quite well. It's just that they shouldn't be used for 3rd party software. Neither should they be thrown away because they fail with that one case.

im tempted to drag out gobolinux again. especially the rootless part.

but then its more or less a new take on the old gnu stow app, that put everything in a subdir under /usr/local, or whatever one set it to, and then symlinked things into the DHS.

but another problem is deciding where the line between distro and third party goes.

is it the kernel and core utils, xorg, or some desktop or other?

still, if there was a system where one could say that these are binaries, these are libs, and these are misc files, and then allow the distros own tools to slot them into the file system where the distro wanted, one would be at least one step closer.

but a lot of paths are set at compile time, and cant be changed afterwards...

Edited 2008-10-11 06:16 UTC

Because...

root@dcom1:~# ldd /{bin,sbin}/* /usr/{bin,sbin}/* | grep libgtk-x11-2.0.so.0 | wc -l
78

maintaining 78 copies of gtk is not only insanely unnecessary bloat but insecure as hell. And I don't even run GNOME. I don't even wanna know what that number would be on a standard RedHat install.

Next question?

bingo, i recall when microsoft announced they had found a issue with one of their core libs.

their "fix"? a program to scan for the problematic lib, as it was something that nearly all programs shipped either compiled in or alongside the binary.

Using that command on my system gives 166!
Ouch...

Why exactly would you install 78 copies of GTK? GTK is clearly a system component. It would be part of the system installation and applications could depend on it being installed.

That command, I believe, does not print out how many times a certain library is installed, but rather, what shared libraries all programs in the given directories use. In your case, you have 78 programs that link to libgtk-x11-2.0.so.0, not 78 copies of libgtk-x11-2.0.so.0 floating around your system. Examine what the output is before you run it through wc, and you'll see that all references point to the same file.

> Why can't Linux implement Apples way of installing?

I think the responses in this thread show it very nicely: Because the OSX way requires certain libraries - most importantly those used by many applications - to be installed as a "core system" such that only one copy exists for them, while the remaining libraries are duplicated in each application that uses them. Obviously, as a system advances and more and more applications use a specific library, it would be incorporated into the core system.

This requires the ability to draw a line between "core system" and "applications". Apple has managed to do this. Linux, so far, hasn't.

And the reason why GNU/Linux systems do not draw such a line is that while Apple is a single entity, there are literally hundreds of Linux vendors. This in turn comes down to the philosophy of having choice.

Strictly defining a "core system" more or less means killing off the concept of distros, which a lot of people would not be very happy about. Choosing "one true distro" over all others isn't really possible at this point either.