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:2006-03-23
the winblows installer way, is _STUPID_. Developers of applications must be only responsible for _THEIR_ little piece of software, they shouldnt have any say whatsoever on how its installed..
Solution:
provide 2 types of packages(hell, only 1 if they are morons).
1: source
2: self-contained directory containing everything.
this is really easy, with type number 1, the user and/or distribution can simply install/package however the f*** they please.
with type 2, if the provider is a moron and makes crappily closed crapware, the distribution can still just repackage if they please, or if the user has a distribution which doesent prefer to package this application, just download the damned tarball, extract it, and RUN the software.. no crappy msi, no weird third party installers doing weird weird stuff, just run..
how hard can it f--king be? its not hard at all, its just bozos not understanding that there IS NO ISSUE
Member since:2007-08-22
[snip]
with type 2, if the provider is a moron and makes crappily closed crapware, the distribution can still just repackage if they please, or if the user has a distribution which doesent prefer to package this application, just download the damned tarball, extract it, and RUN the software.. no crappy msi, no weird third party installers doing weird weird stuff, just run..
how hard can it f--king be? its not hard at all, its just bozos not understanding that there IS NO ISSUE
Actually, that only works for a small sub-set of programs. Consider the impact of shared libraries? If the program is not setup to pickup libraries out of wherever the distribution wants to have them (and there are programs out there like that - like it or not) then your whole solution breaks down for commercial applications - the biggest violator of such.
A lot of company's do not want others using the libraries. They write the libraries for their own use. They don't provide headers to those libraries. Those libraries do not belong in the /usr/lib or /usr/local/lib directories as a result. They belong with the application; yet a distributor designs things to be put in common areas (/usr) - they don't want things in other places (e.g /usr/local/someapp/).
Get over it already.
You may think it's broken; but it's a fact that has to be dealt with for commercial applications. Whether its an Adobe application or some random piece of shareware. That's the reality, and not one distributions are going to fix either.
As another example - distributions break things too. For example, Aaron Seigo's recent blog (http://tinyurl.com/54upvd) about distributions packaging software in a way that does not help developers. If the developer's controlled it, it would be packaged as needed. (As stated before, F/OSS developer's typically don't want to package anything.)
Honestly, there are two different communities being talked about here: F/OSS and Commercial. And they both have different requirements and expectations on how to package software. If we (the F/OSS community) want commercial applications, then we have to provide some way for them to be able to package software their way too, and your "solution" does not address it that way - its a 'my way or the highway' approach, which is not going to win over commercial software vendors.
Like or not that's the reality.
Member since:2006-02-05
How is MSI stupid? On the windows platform you can script any installer for any package, and deploy it across any number of machines, customized according to group policy.
2: self-contained directory containing everything.
this is really easy, with type number 1, the user and/or distribution can simply install/package however the f*** they please. with type 2, if the provider is a moron and makes crappily closed crapware, the distribution can still just repackage if they please, or if the user has a distribution which doesent prefer to package this application, just download the damned tarball, extract it, and RUN the software.. no crappy msi, no weird third party installers doing weird weird stuff, just run..
Deploying to a home desktop and across a big network and wildly different things, and aren't really comparable.
To create more advanced package management tools, you need a standard format to work against. The lack of a standard format means the inability to build robust tools for large scale deployments.
There are distro specific tools that are up to the task, but that means you are stuck with the package selection the distro provides you (or take on the burden of packaging yourself). It would be a far better solution if the project itself could take care of packaging (since they know more then anyone else what is supposed to be going on), and have that seamlessly integrate into whatever package manager a distro happens to be using.
Edited 2008-06-23 20:20 UTC
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
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:
2007-08-22
That's exactly the problem with requiring every company to release everything so that each individual distribution can carry it in their own format, on their own terms.
theres really no great big mystic problem, its just that most people dont understand a flying f--k what they are talking about, and makes lame excuses because their software stinks.
Please take your own advice here.
Fact is - it is far simpler to have a standard API that someone can write an installer to and for software developers to provide an installation package for (e.g. MSI, InstallShield, Wise Installer, etc.) than it is to get everyone to do things the way *you* want it done and for each individual application to be turned over to the great distributors to send out to the users.
Fact is - non-F/OSS applications will never get picked up that way. Yet there is a great demand for them. (Yes, I prefer F/OSS when available.)
Fact is - not every distribution is going to package every piece of software under the sun. They can't. They don't have the time to.
Fact is - every distribution wants to do things slightly differently. So standardizing on a single package manager isn't going to work, and telling a company to produce packages for 10 different package managers is just insane.
So please, get past the bull, and realize that for a major desktop supporting commercial applications is a must, and to support them the package systems (package managers, etc.) have to get beyond the idea of controlling everything down to the package format. All they need to control is what is installed, and that does not have to be in the package format.
To quote MSI as another example - I could use Microsoft's MSI packaging implementations (WiX, VS Installer, etc.), or go out and get other solutions (InstallShield, Wise Installer, NSI, etc.), or just write myself an EXE that uses the MSI API to do perform the back-end tasks. MSI itself doesn't care.
RPM, PKG, DPKG, etc. can all learn a lot from MS's MSI system. MS could learn a lot from them too; but MS does get what the commercial interests are - and not everyone wants to open-source their code base. (Not everyone can even if they wanted to!)
One solution for example: Take an MSI type installer, make the interface tell it explicitly what files are installed and where so they can be tracked in the package system's database; provide a compliance program that tests to make sure that no other files are installed elsewhere. It'll achieve the same result, and allow for a far better system overall.