To view parent comment, click here.
To read all comments associated with this story, please click here.
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:
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.