The Future of Packaging Software in Linux 595
michuk writes "There are currently at least five popular ways of installing software in GNU/Linux. None of them are widely accepted throughout the popular distributions. This situation is not a problem for experienced users — they can make decisions for themselves. However, for a newcomer in the GNU/Linux world, installing new software is always pretty confusing. The article tries to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux."
Applications Packages (Score:5, Interesting)
Seriously, drag-n-drop installation rocks.
Re:The solution! (Score:1, Interesting)
Re:Applications Packages (Score:1, Interesting)
Seriously, being able to read a linux story without inevitable, (innaccurate & irrelevant) OS X comparisons would rock.
How about we take the easy way out? (Score:4, Interesting)
That way there is no need to worry about "replacing" the existing systems. You can instead focus on evolving them to meet the requirements. Even if each distribution/project takes its own path to get there.
#1. It must make installing new software as easy as it currently is with apt.
#2. The same for upgrading the software.
#3. The same for removing the software.
#4. The same for handling dependencies. Including the order in which dependencies must be installed.
#5. The same for validating the installed software against the original software (checksums or whatever).
#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.
#7. The ability to point the updater at your own repository or multiple repositories.
#8. The ability to recompile (automatically) any software that you install for your specific hardware.
Anything else? Yeah, I know most of this is already handled with apt. But that's what I'm most familiar with. I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation).
The hard part... (Score:4, Interesting)
Eventually, with RPMs, for example, I end up getting to the point that I have to force something, which shouldn't ever really have to happen... but it does.
not really (Score:3, Interesting)
All I need to do is search for something in the package manager GUI, click the its checkbox, click "apply", and I'm done. It's even easier than downloading a dmg, because you've got to go out and find that dmg on the publisher's website, or versiontracker or whatever. I simply express a desire for that program to be available, and then downloads, installations, updates, etc are all handled by the package manager. This even works for proprietary software (eg I have Nvidia's binary drivers, Adobe's Flash and PDF reader, VMWare Player, etc installed through my distro's package manager).
The best solution is for the vendor to supply whatever they're going to supply in a tarball, and then let the maintainers figure out what the dependencies and so forth are.
Re:Nonissue (Score:2, Interesting)
Hell Yeah! (Score:1, Interesting)
For example, all my wife needs to know is: open Synaptic when she needs some software. Or even (gosh, how difficult) look for software on the Internet, open Synaptic and type the name in.
I believe the article is missing/trying to say that regardless of the package method used CNR will provide a wrapper for all of them. So the solution is not to create yet another method (that will never work), but embrace all the existing ones in an easy-to-use interface.
That interface will be provided in both Freespire and Ubuntu Feisty. It should be good for newbies, hardcore Linux people will hate it (although that doesn't matter: it's not aimed at them).
Re:Applications Packages (Score:1, Interesting)
In the end the debian folks were much kinder, and helped me out.
Re:How about we take the easy way out? (Score:2, Interesting)
Make it easy to install software that has DIFFERENT dependencies.
The classic example I always give is LDAP - you either want it or you don't. However why should I install LDAP because some application decided to link against LDAP? Or conversely, what if the application was NOT linked against LDAP and I want LDAP support in the app (which is available in the app itself).
Unfortunately, the only real solution to this is source based installs or having a compile for every combination of dependencies. But possibly something that will allow you to specify dependencies, and if you break from the 'blessed' dependencies, still has the ability to compile the base version (with no extra steps required by the user apart from saying 'yes, OK, do the compile'). Without requiring it to recompile ALL packages involved (ie. if the LDAP is coming from some library used by the app you requested to be installed, it should only recompile that library, not everything or the final app (since its using shared code and not using LDAP directly).
And as an addition to that, there should be a way to 'offshore' said building to a build server (or servers) - that will keep the package once built (with record of its dependencies) - so that if you are deploying on a large scale, you can use the SAME package manager that comes with the default distro on ALL your boxes, and install your package with custom dependencies (triggering a compile), and then when you install that package with the same dependencies later, it will just pick up the pre-built version, just as if it came from the official pipe.
These kind of problems are rarely solved at all by packaging systems, and usually installing from a source archive for a single package on a binary distribution is a pain in the neck - especially if you want to actually build from a source archive with ALTERED dependencies. Right now, only completely source-based distributions allow you to change dependencies, but then you need to pay the penalty of building EVERYTING (yes, Gentoo and such have their pre-built packages for large modules like Gnome or KDE, but you still end up building a lot).
Basically, I'm saying I could not really use a binary packaging system unless it had the ability to fall back to source altering its dependencies (which means the package needs to know HOW to compile disabling and enabling certain things (ie. configure flags), not just how to compile the same way the binary distro was made), and do so seamlessly and without forcing the user to go though 7000 additional steps or have intimate knowledge of how to compile an application. Remember, from the amdin's point of view, they just don't want to install LDAP unnecessarily, they don't specifically want to have to know how to recompile XYZ package to exclude LDAP support, or even if they know how to, want to have to do that for every package that is optionally supporting LDAP using manual procedures to disbale LDAP support.
This, and the fact that getting 0-day releases for certain packages when a new version comes out (sometimes a new release fixes a specific bug you have been waiting to be fixed) without having to recompile it all myself and break the packaging system or have to get more intimate with the packaging system than I want are the reasons I switched back off of Ubuntu and back to Gentoo. I tried Ubuntu because I wanted to see what life would be like without having to compile all the time - but in the end found I could suffer the compile (especially with things like distcc) to have a system the way I like it without extra crap installed because it happened to be compiled with support I don't need, want and will never use.
PreZ
Re:The solution! (Score:3, Interesting)
Choice is good - until the point where it becomes totally overwhelming. On linux there are dozens of distros to chose from (different versions of the said distros too - running on different versions of the kernel), different window managers to chose from, different installers (apt get or whatever, applies to both the command line and the graphical installers), different package formats, different shells, too many different text editors (vi/emacs/...) and such.
Most users appreciate SOME choice. Like when you go to the dealership, you pick the car model, the engine, color and such. The linux way, you'd be forced to hand pick things like the actual metal alloy used for the pistons' segments and such intricate things most people couldn't care less about. Yes, you could have a totally custom car, but it would take 6 months to pick all the parts by hand, and comparing the cars to another would be so complicated and overwhelming...
Too many confusing choices to make, often over stuff one doesn't really understand. And when searching for information about them (to make the choice), often all one finds is heated debates (like kde/gnome or emacs/vi) without much real information.
When I use my PC at home, at work, on the road, at friends or relatives' places, it's always the same interface (plain old WinXP), same way to do things, stuff located in the same places, most apps are the same, etc. Predictable, consistent and simple. Most people truly appreciate that.
If we were all running linux, I'd be using say, KDE or gnome, work might be using fluxbox, a friend would use something like xfce... All on different distros that work differently and have different apps installed by default (likely not the ones you're used to). I'd be lost.
Re:Applications Packages (Score:3, Interesting)
Re:Applications Packages (Score:4, Interesting)
Re:Applications Packages (Score:1, Interesting)
Pleeeeaase. Where else would I get up-to-date software, when the Ubuntu guys don't provide it?
Seamonkey 1.1 installed just fine. Java 6 installed just fine. JEdit (dev version) installed just fine. Eclipse installed just fine. NetBeans (dev version) installed just fine.
The only problem might be that many developers don't provide installers in addition to RPMs or DEBs. But that's really THEIR problem. A sensible developer would provide a general-purpose installer for any Linux.
Re:Applications Packages (Score:3, Interesting)
Re:How about we take the easy way out? (Score:3, Interesting)
Why is this funny? There's nothing evil about a silent mode. It's called "ease of use". In fact, I was kinda under the impression that ease of use was the point of this article. If you like screens of text, set a verbose flag. If you like pulling wires, you can still build from code.
Or is the goal to continue to scare people away from widespread adoption?
Re:The solution! (Score:5, Interesting)
Which is why, as it currently stands, this year will not be Year Of The Linux Desktop. Consumers won't just accept that they can't install software X because it's an RPM and alien doesn't work (this is of course after looking online for half an hour to figure out that alien is the tool to use). Manually compiling from source is simply not an option for standard users. Sure it's a dandy idea, and if you get a "fullproof" GUI that handles the compilation and installation then maybe, but I can't count the number of times make/make install has failed for some obscure reason. The first time grandma needs to go download dependencies means Linux has failed on the consumer desktop.
This is one place that Microsoft and Apple have it right. By having a standardized method of installing and storing program information they make getting new software many times easier than on Linux (excluding the "normal" packages. I'm thinking more along the lines of tools and apps you download from the web). This is also one reason people are willing to pay for an operating system that has a standardized and dependable way of doing things.
Microsoft even released the WiX toolkit [sourceforge.net] that allows anyone to create MSI installer packages. MSIs are one of the best ideas for Windows in a while: No more dealing with poorly-written homebrew installers or 10-year old, 16-bit InstallShield programs. Instead you have a fully scriptable installer that's transaction-based and has near 100% support coverage.
I like apt, but downloading a gzipped file of source or a deb that complains about dependencies still can't compare to an MSI package. Even if a solution was developed that worked as well as or better than MSI, as you say, it would take significant effort (and maybe not even then) to get it supported by all the major distributions. Some people seem to think that the fact that Debian does things differently from Mandriva that does it different than Fedora is what makes the distribution "special". Be that as it may, I think it's only hurting Linux users as a whole.
Re:How about we take the easy way out? (Score:3, Interesting)
Number 1 should be:
Allow commercial and proprietary software the same distribution channels are open source software.
Until that happens, there will be no commercial software on Linux. Not only do current Linux package managers not facilitate the installation of commercial or proprietary software, but they are also designed in such a way so that installing a commercial/proprietary package is likely to break the package manager, requiring an extensive repair process next time you run it.
Linux will never have a strong software ecosystem unless commercial/proprietary software is allow to compete on an even keep with open source software.
Re:The solution! (Score:3, Interesting)
WiX is fully open source, so if you wanted, you should be able to figure out how to create MSIs from that. In any case, you could try running it under Mono, maybe it'll work under Linux...
Most of those EXEs are actually MSIs wrapped with a stub installer that can install the Windows Installer if it's missing.
Well..... yes. It is. Sort of. It allows arbitrary binary code to be run - but then again, it's an installer. It could run arbitrary code anyway. Complaining that MSI is "another executable format" would be like complaining that RPM is "another executable format" - it's equally true. (Although I think RPM generally runs shell scripts, not direct binary code. Although I could be wrong.)
Right, nobody does that because it's practically impossible to get it working. Instead they discover that it's not in the apt repository and give up. That's the problem with the Linux packaging system - if it's not there already, it's basically impossible to install unless you're a Linux expert. Now you might say that "any software you'd ever need" is going to be available, but you're guaranteed to be wrong at some point. Some new game, some new app, something will become available that someone will want to install - and won't be able to, because it's not in the distribution repository.
Worse, from the developer point of view, they might create some great new software that they want to release in an easy to install form - and, really, can't. Maybe they'll generate an RPM or a DEB for their own installed Linux distro, but beyond that, it's just too much effort to try and make an installer for everyone.
Oh, and MSI is horrendously overcomplicated compared to RPM and DEB, in case you wanted to know. Nothing like having to generate a GUID for every single file you might want to install. (Although to be fair, that's likely because most Windows programs don't contain all too many files.)
Re:The solution! (Score:1, Interesting)
Boy do I disagree with this statement.
If you make it too easy to run such that no OS is responsible for the software that is installed from anywhere on the internet. What's the difference from this and malware that runs rampant on Windows -- where it is pretty painless to install anything from anywhere.
Re:The solution! (Score:3, Interesting)
What the Gentoo devs need to do is to add arches like x86-bin, amd64-bin, etc. to the Portage tree, and these arches would not compile anything--just install binary packages. Every time this is brought up, many Gentoo devs jump to the defense of building from scratch, saying "if you don't want to build from scratch, what the hell are you doing using Gentoo?" And I usually respond with something along the lines of "but isn't Gentoo all about choice? And shouldn't I have the choice to install binary packages?"
The binary packages would be standardized on a certain set of USE variables, and only compiled for each arch/CHOST combination (to reduce storage costs at the repositories). If someone needs a specific set of USE variables for a particular package, they can build from source by specifying a non-binary arch in their
The beauty of Gentoo is scalability; the system can be tailored to be anything you want it to be. This will add one more option: Gentoo can also be a binary distro, suitable for non-hardcore users. If Debian can do it, why can't Gentoo?