Installing software on Linux. In the world of online minefields, this is the big one. Back in the day, you installed software on Linux by compiling it manually. Time-consuming, but assuming you had a decent knowledge of gcc, make, and maintaining library files, this could actually work. Later one came the package management systems that were supposed to make installing software on Linux a breeze: rpm, dpkg, and so on, and so forth. Since human beings have the innate tendency to assume that everyone else is wrong and only they are right, we are now stuck with 3453495 different Linux package managers. Denis Washington, a Fedora developer, is taking steps to resolve this issue.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2007-08-22
MSI itself is not really a package manager by any means. Rather, it is an API that software can use to tell the system that it is installed, where, and how to uninstall. It is certainly a key component to a package manager. MSI does provide a "package format", but you need not use that format to use the MSI API; though most do. MSI has certainly brought Windows closer to providing a package manager - that is certain - as nearly every installer program for Windows has switched to using it.
However, even some Microsoft tools still do not use MSI as the primary source of their installer (so far as I can tell) and use a mix of MSI packages and non-MSI packages; yet the whole thing is registered through MSI with Windows as being installed.
The difference between MSI and a package manager is that MSI is focused on how one piece of software installs into the system. There is nothing in it for dependencies or anything else of that nature. There is no repository being MSI from which to grab all kinds of stuff. And perhaps that is what you are thinking can be done with RPM/DEB/etc and not MSI - but that is exactly the case because MSI is not a package manager; it is a package installer, nothing more - and the two are quite different.
Perhaps that's why you're so confused - and think there is so much confusion - with respect to Windows.
Also - you don't see the RPM/DEB/etc guys porting their stuff to Windows either. You do see F/OSS software ported to Windows, and then the projects usually end up providing a nice MSI installer for it, which works very well.
Member since:2006-11-17
The point is that MSI is just another way to install software, be it a layer on top of the package manager, this is what packagekit or CNR are.
It may seem like a good idea at first: let's unify all package managers under one API that everybody can use. This is not such a good idea actually, because you just create another library that need to be installed everywhere to replace everything, but actually only SOME people will use it, but never all and your API will only add to the confusion. What you need is not create another API, but to collaborate with those that already exist. rpm is fine as such, MSI is fine as such and dpkg is fine as such. The problem is that they all exist separately.
The confusion is not MSI, the confusion is that you have one way to package software on Windows, one way to package software on Mandriva and one way to package software on Debian, but a package created with MSI won't work if you don't have the libraries installed, a package created for rpm won't work if rpm is not installed and a deb package won't work without dpkg.
By default, Mandriva doesn't have MSI nor dpkg, Windows doesn't have rpm nor dpkg and debian doesn't have MSI. Fortunately, there is alien to convert packages between rpm and deb and wine to use MSI on Debian and Mandriva and this is the way to go: instead on adding just another layer on top of the package manager (so called package installer) which just adds to the confusion, we need to reduce the number of package managers and make bridges between them.
In other words, creating something like MSI but not MSI on Mandriva or Debian or Suse does just mean that the software that use the MSI-like API will only install where the MSI-like API is available, that is to say nowhere or maybe one or two distros. On the other hand, rpm, dpkg and MSI are already available on many machines. Porting rpm to windows would be a way better idea. Already too much package managers and confusion.
Member since:
2006-11-17
MSI is just another package manager that adds to the confusion. I don't see Microsoft doing anything to make MSI compatible with autopackage, dpkg, rpm or any other package manager. If you package your software with MSI, it will only install on Windows. That's not better than doing a rpm that will install only on Mandriva or a deb that wil only install on Debian.
Of course, there are more people running Windows than Mandriva and Debian put together, so the problem doesn't show on Windows and it looks like it is a good way to distribute software, but really it's just the package manager of Windows and it's not better than rpm or deb. I can't think of anything that can be done with MSI that can't be done with rpm, but I think about a lot of stuff that can be done with rpm but not with MSI, and even more with urpmi, apt-get and yum.
I mean, the problem is not with rpm or deb. The problem is that 1000 people have MSI installed when 1 man has rpm installed and 1 man has dpkg installed. Add another api on top of rpm and dpkg, and maybe 1 people will have that installed.
So, if you are a software vendor, what will you use? the new api (1 user), rpm (1 user), deb (1 user) or msi (1000 users)?
Anyway, MSI is available on many distros (including Mandriva and debian) with wine. wine implements MSI.
Edited 2008-06-24 08:20 UTC