Slashdot Log In
The Future of Packaging Software in Linux
Posted by
Zonk
on Mon Feb 19, 2007 01:39 AM
from the come-together-right-now dept.
from the come-together-right-now dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
The solution! (Score:5, Insightful)
Re:The solution! (Score:4, Funny)
Parent
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).
Parent
Re:How about we take the easy way out? (Score:5, Informative)
What pisses me off is the 32 step process to making a deb (that's what dpkg calls a package btw.. just incase you're playing acronym bingo out there). So if you want to install something you built from source, and be able to remove it later, you need some freakin' magician to have made it into a source package.. cause there's no way in hell you're doing it yourself.
What really depresses me is that debs, dpkg and apt, that's about the best anyone has done. Unless, of course, you actually like building everything from source.
Parent
You want "checkinstall". (Score:5, Informative)
Checkinstall http://www.debian-administration.org/articles/147 [debian-adm...ration.org]
It's not the answer to all issues regarding installing from source
Any suggestions on what would make them even better?
Parent
Re:How about we take the easy way out? (Score:5, Insightful)
Parent
Re:How about we take the easy way out? (Score:5, Insightful)
Parent
"Roll-backs" or "back-rev'ing" would be good. (Score:4, Insightful)
In fact, Ubuntu might be switching to the Smart Package Manager http://labix.org/smart/faq [labix.org] which seems to support this functionality.
I also left out
#10. Mark packages so that they will NOT be upgraded. The same as I can do with apt.
Parent
Re:The solution! (Score:5, Informative)
Using multiple package formats is great idea, IMO. I use alien on Ubuntu for those situations where the software I want is only avaliable in RPM, but as it says in the summary, new users can be a bit confused by this and building from sources is often too much. I would like to see GUI tools get the smarts to automatically figure out dependencies across all formats, allowing all distros to become package agnostic. Perhaps Linspire's CNR interace would be a good candidate for this.
Also, the option to resolve dependencies and install as a statically linked blob would be awesome for legacy stuff. I've lost count of the number of times I've wanted to install an app, only to find that it relies on some obscure version of xyz.so and won't work, so I find the source for the old version of xyz, only to find it depends on some older version of abc.so. If I could get this xyz.so, etc without conflicting with that xyz.so, create a static binary and put it somewhere under /opt, I'd be happy. I know it's not elegant, and that it uses more storage, but as a work around for difficult to support stuff, it ain't so bad when storage is cheap. Some apps I always install as blobs anyway, such as blender.
BTW, from TFA: Network Access Message: The page cannot be displayed :-(
Slashdotted
Parent
Re:The solution! (Score:5, Insightful)
The package formats are easy. The real bastard is that each distro has subtle differences in how the packages and the dependencies are organized. The only way that I can see to fix that is to design a universal package tree, and convince all the major distros to conform to it. Which is not impossible, but it aint easy, either. And it might cause other problems.
Parent
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.
Parent
Re:The solution! (Score:5, Insightful)
They don't. Linux users install software out of their software catalog. Occasionally the brave ones go to the author's website, and download the software from there.Bzzt. Wrong. Nobody is willing to pay for Windows, that's why Microsoft doesn't let OEM's give you a choice. Duh, I'll use the Windows I already bought. And don't spread that Lie about how I don't have a License to.But not the MSI format specification. That would allow me to cross-compiler into an installable package. As it stands, my users who run Windows have to deal with no installer.You're wrong, and you want proof? Look how many programs- nay, look how many programs come from Microsoft that are still distributed as exe files. That shiny new Zune's software comes in exe-form.
Once that 16-bit installshield program was written, it's forever supported. You can't put the setup.exe genie back in the bottle, and you have to live with that. With Free Software, we can take our software library with us, which is why Free Software always gets better, and non-Free software atrophies.You are wrong on all counts. Pull the power plug while installing and you'll see just how transactional it is. I don't even think you know what coverage means: Microsoft Support will tell you to reinstall your operating system if a broken/corrupt/poorly-written MSI breaks your system. Even if they make it.No of course not, but that's why you used a straw man. MSI is an executable, and just made Microsoft's security problem worse: it introduced yet another executable file format. Nobody downloads "gzipped file of source or a deb that complains about dependencies" ever. They say "apt-get install xyz" and it goes and figures out the dependancies itself.
It doesn't have to- Linux users could waste disk space by including the dependencies with every program- and some Linux distributions even do this(!), but it makes upgrades very difficult. For example, when libz had a vulnerability discovered, only one copy needed to be upgraded on most Linux systems. On Windows, almost every program that dealt with gzip or deflate-compressed data (like png or zipfiles) needed to be upgraded. Worse still, that library or program can be anywhere on your hard drive, and you might never know it.
Parent
Re:The solution! (Score:5, Informative)
I personally like the package management system. I like having one place to look for software for my system, software that I know has been tested with the programs I likely have on my system, software that I know will update with the rest of my system, software I know isn't spyware. It sounds like it wouldn't work too well, but it really works rather well since there are so many programs in the repositories. Even for the programs that don't want/can't be in the repositories, there's ways for people to install those easily as well. There's java programs that install easily regardless of your Linux, there's autopackage, and some developers just put the program and all the files in a zip file that you can extract and then run where ever you want. There are solutions, they probably need better development, but they're not in terrible shape and that's not the most pressing issue for Linux. Much more important is getting the software people really want on Linux (or at least working really well and easy with wine) and making really good oss equivalents to proprietary software (we need something better than gimp to compare to photoshop) and we also need more device drivers, especially wireless. Those are much more important than package management.
Parent
Applications Packages (Score:5, Interesting)
Seriously, drag-n-drop installation rocks.
Re:Applications Packages (Score:5, Insightful)
The reason Linux distributions have not been trembling to adopt the OS X style of package management, if you can call it that, is that it would be a poor fit for the Linux software ecosystem.
The vast majority of software used on Linux systems is licensed under the GPL; what is not is almost always under another license permitting free redistribution. This gives Linux distributors great freedom in selecting and assembling a compatible collection of versions, tested and working with the same versions of dependent libraries. In a larger distribution (such as Gentoo, Debian, or Fedora), most of the software you will ever need is already a part of the OS -- you just need to use the built-in package management tools to summon it from the distributor's repository.
OS X-style package management is best suited for a software ecosystem in which users draw software from a large number of heterogenous third-party sources, while the core OS and iLife suite are maintained and updated by Apple. A third-party distributor who wishes to distribute something that must link against a particular version of a library can include it in the application bundle, knowing that the exact version needed will be available. This can lead to many copies of the same libraries being installed, facilitating compatibility with applications that require different versions, but consuming (small amounts of) disk space unnecessarily and increasing the attack surface when multiple copies of an exploitable library are installed on the system. A system such as APT does not need to provide a facility for private copies of libraries, since it does all of the dependency computation, and all software in the repository is built and linked against the libraries in the repository.
Certainly, once you have resigned yourself to visiting a third-party distributor's web page, manually downloading a binary package, and then manually installing the binary package, drag-and-drop installation is very convenient. But the Linux software ecosystem does not require this concession from the user -- the Linux distributor is free to provide a repository and tools for finding, installing, and updating software, without the need for manual installation.
Parent
Re:Applications Packages (Score:5, Insightful)
Unless the software you want isn't in the Synaptic repository. Then it's hell on earth for the average user. The only response they get from support and developers is, "Why would you want to use software that isn't in the repository?"
Actually, that's not true. There are plenty of other fun responses:
"You should compile it from source."
"The vendor should spend his time getting his software added to our respository!"
"Use RPMFind. I'm a developer and I've never had a problem installing binary packages on the distro I work on." (Conveniently ignoring that when something breaks, the "developer" fixes it himself.)
Not that there's much point in harping on this again. I'll just get the same, "U R STUPID", "You need to try distro XYZ", and "Everything is in my distro's repository!" answers I've gotten before.
Blinders on, and full speed ahead cap'n!
Parent
A total load of bullshit, and here's why (Score:5, Informative)
You padded the Mac list with the following:
Your Debian list conveniently leaves out having to click the KDE start menu, fire up a Terminal window, type in the root password, waiting while the package manager goes through dependencies, etc. What a phony comparison of steps. I could just have easily reduced OS X's step to one line of "Drag app icon to Applications shortcut" in the same the way you reduced Debian's steps.
Parent
The five ways (Score:4, Informative)
1) Installing directly from source code,
2) Ports-based installation (where the source packages are held in a repository and can be automatically downloaded, compiled and installed), like BSDs ports of Gentoo's portage,
3) Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
4) Installing from distribution-independent binaries (most proprietary software is delivered this way),
5) Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.
RPM gets a nod but.... (Score:4, Insightful)
Hasn't explored other packaging methods (Score:5, Informative)
Re:Hasn't explored other packaging methods (Score:5, Informative)
Circular dependencies, aka RPM hell, is what actually prompted me to make the switch from the Red Hat family to the Debian family. I used to be a pretty die hard Red Hat user. It used to be that Fedora was the cutting edge, back in the core 2 and 3 days. I would have those days when I would wrestle with the packages, but I just took my hits and moved on. Then Ubuntu came along, and I realized how much time I was wasting with that stuff. It "just works." APT is great (it's a pity POSIX decided to go for RPM). Gentoo's portage is really cool too, but IALAB (I'm a lazy bum--if you can't reconcile the acronym, then you probably shouldn't know what the missing word is).
Parent
goddammit (Score:5, Insightful)
I'm not in the mood for a holy war right now, but for fucks sake, Debian perfected package management a decade ago.
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.
Re:Nonissue (Score:5, Insightful)
Then realize you're basically accepting that Linux will never make a significant dent in the Microsoft+Apple consumer desktop market. You may be able to compile the source code, the rest of us either don't know or don't care. Either Linux is going to be a OS for users, or a OS for geeks. It can't be both because geeks will try to escape a OS too user-centric, and users will escape a OS that resembles the inconsistency caused by groups of splintered geeks.
Parent
Re:Nonissue (Score:5, Insightful)
Linux will never make a significant dent in the Microsoft+Apple market by doing the same things the same way as Microsoft and Apple.
Look at markets where Linux has succeeded, such as servers and embedded systems. Linux succeeds *because* it doesn't follow the Microsoft license model, the Microsoft development model, the Microsoft business model, and so on. You can't win if you play by Microsoft rules.
Linux can be, and is, an OS for users. It isn't an OS for third party closed source binary distribution. Don't read that as non-commercial; commercial software was distributed in source form before Microsoft and will be again. Distribution in binary form makes sense for games and art, but not for general purpose computing. The value of doing things in software rather than in hardware is that software is malleable. But you need the source to realize the full value; binary distribution removes value.
So yes, Linux will not make a significant dent in the Microsoft+Apple consumer desktop market, if that means the closed binary sales market. If Microsoft played in the NFL, they'd be the Super Bowl winning Colts. But the Colts will never win the World Cup, which is worth more. Don't complain about Linux not hiring a bigger front line when the game Linux is playing is soccer, and doing rather well at it.
Parent