Linked by Thom Holwerda on Mon 23rd Jun 2008 16:51 UTC, submitted by sjvn
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.
Permalink for comment 319601
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
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.