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 read all comments associated with this story, please click here.
Member since:2006-03-23
companies want lives easier? then stop trying to control EVERYTHING, that shit just work in this world.
they need to release their stuff properly, this way, every distribution can package it as they please, plus users can just use a generic release if their distribution doesent carry the package..
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.
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.
Member since:2006-02-05
This is one of the weaknesses of massive distributed systems like open source, sometimes you need someone to say "Do it that way and don't argue with me." you can't really do that, because there is noone really in charge.
My money is on autopackage as the thing that will save us all too. I had honestly hoped that by now it would have gained more traction then it has though.
Member since:2006-01-16
Autopackage is out of the question because it enforces libc usaged from a C-like program (for compiled apps). It doesn't work without certain "libc path" hacks, which are impossible to do if your binary doesn't use libc at all (say it does syscalls via other interface).
Member since:
2007-08-22
In the form of Autopackage:
http://en.wikipedia.org/wiki/Autopackage
http://www.autopackage.org/
There's also others (see the other posts); but it's still the same kind of thing that is needed. (Autopackage is really only complicated by the fact that it tries to mitigate the LibC API too.)
Seriously. The distributors need to realize that commercial software (freeware, shareware, companies, etc.) want control of how they package software, and there needs to be something that mitigates this.
Under Windows you have MSI - which InstallShield, Wise Installer, and everything else work with. And really that is the same kind of thing that the F/OSS world needs to. If a distro wants to use RPM, DPKG, PKG, or e-builds - fine.
Of course, this all boils down to the question of: Who is going to generate the package? And F/OSS developer's don't seem to want to do so for their own stuff - while everyone else wants to. So we need a method for both.
It'll make life a lot easier for companies too.