Slashdot Log In
The Future of Packaging Software in Linux
Posted by
Zonk
on Mon Feb 19, 2007 12: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: (Score:3, Informative)
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:4, Informative)
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
Re:The solution! (Score:4, Insightful)
This is one of the places Linux gets it wrong. My operating system should not be responsible for all the software I might at some point want to install. Windows messes this up too at times (IE), but MS is much less of an offender than Linux is. It should be responsible for making it easy to install new software, among many other things, but it should not be responsible for every software program out on the web.
An operating system should be responsible for the kernel, file system, and the nuts and bolts of keeping the system running in general. The program creators should be responsible for packaging so that it can be installed (with the help of the operating system) and should also be responsible for dependencies. It should not be my job to spend three hours searching the web for some obscure package that the program creators just couldn't do without. If they see it as necessary, and they know its not readily available, they should package it with their own program (GPL and BSD licenses both support this and is one of the strengths of these licenses).
Parent
Re: (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 appre
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
MOD PARENT UP (Score:3)
Re: (Score:3, Informative)
#1. It must make installing new software as easy as it currently is with apt.
up2date -i [package name]
"This package will require the installation of these additional packages, accept?" Yes/No
#2. The same for upgrading the software.
up2date -u [package name]
"This package will require the installation of these additional packages, accept?" Yes/No
#3. The same for removing the software.
rpm -e [package name]
#4. The same for handling dependencies. Including the order in which dependencies must be installed.
Already done, see above. up2date will find dependancies, dependancies of dependancies, etc. until it is done, then present you the list and confirm to install all the packages, you hit "Y" and you're done.
If you just want to check what would be a dep
Re:How about we take the easy way out? (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
- Link it into the menu/desktop system
- Also link in help or documentation, or at least a relevant URL
Even somebody who has used Linux for many years and feels comfortable with apt, rpm etc, can still occassionally be annoyed as all hell when an application is installed, then you have to go searching all over the web to find some basic configuration guide, let alone finding how to start the app.
In fact, maybe part of the packaging system could include l
Re:How about we take the easy way out? (Score:4, Insightful)
Software packages should *include* the upstream documentation. That way, the user gets correct documentation that matches the version of the software they installed. If the documentation is very large, it can go into a separate foo-doc package.
The other advantage is that people using the software offline can access its documentation.
Parent
Re: (Score:3, Insightful)
#11 - The ability to have a user install their own package easily a
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: (Score:3, Informative)
Re: (Score:3, Informative)
At least in the RPM-speaking world, we already have this functionality in the SRPM, though not in a formalized sense. Often, compile-time options require only very small changes to the spec, or can be given on the command line. For example, the bytecode compiler option for mo
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: (Score:3, Informative)
Because you can't install RPMs on DEB syste.. Oh wait, you can.
Most distributions let you convert&install/install other package formats, this article's problem is a non-issue in my opinion.
And no, I don't think drag and drop is easier. I just want to type the application name I was to install and that's it. Not having to worry about updates etc.
The OS X method:
Find website of program
Download program
Op
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
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, instal
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
Re: (Score:3, Insightful)
I love your evidence though. "Appears to require 4GB of ram." Right, dude. Right.
Re: (Score:3, Funny)
Re: (Score:3, Interesting)
Re:Applications Packages (Score:4, Interesting)
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
Re:Hasn't explored other packaging methods (Score:4, Informative)
So package foo depends on package bar, and package bar depends on foo.
All you do is:
rpm -Uvh foo.rpm bar.rpm
Circular dependency solved. The circular dependency 'problem' (it never actually really existed) was more of a problem of lack of good documentation than a problem with the actual 'rpm' program. However, this is a problem that was solved years ago - I haven't used a distro in the last 5 years that hasn't had a system like yum, up2date or apt which does all the dependency resolution for you.
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.
They don't care about the file ext., fix the list (Score:3)
GRAPPLE - GNU Remote Authenticated Potato Peeler Library for Emacs
If the chosen package manager cleans that up, or at least moves it from Big Long List to the more fine-grained categories a la download.com, the first-time user isn't going to care whether the package is a tarball,
sigh... (Score:3, Insightful)
Linux, unlike proprietary, closed source software is about choice. That's what I LIKE about Linux--I can choose the way that I prefer, be that how to install packages, which desktop environment to use, which CLI shell to use, if Linux boots into a CLI shell or if it goes straight to X-Windows, etc.
*BIG sigh* Why not ask the mainstream users? (Score:3, Insightful)
One of the previous episodes of Drawn Together put it best:
Spanky (to the TV Reviewer): No wonder you hate the show so much. You're everything we make fun of! You're a Jewish, conservative, pro-life, born again, overweight, Asian, homophobic lesbian broad who cuts herself!
Reviewer: So?
Spanky: So, maybe someone who doesn't happen to be a Jewish, conservative, pro-life, born again, overweight, Indian, homophobic lesbian broad who cuts herself might not be offended by our show.
Reviewer: I have every right to tell people what I think of your show.
Spanky: Yes! But people should know you're not our audience, asshole!
You aren't making an OS to appeal to the guy in the cubibicle next to you in the CS class in college. You're making an OS, by your own claims basically, to overthrow the evil overlords (AKA Microsoft, if you ain't got it yet). So why is this STILL a debate today?
Keerhist, I'm a furry artist, and even I recognize the concept of a limited market margin, but I don't spend my time in debates and having epileptic fits or Tourettes outbreaks in order to try forcing non furry fans to accept what I draw. Jeeze.
No one really cares... (Score:3, Insightful)
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
Re: (Score:3, Insightful)
Most users don't know what compiling software is, let alone how to do it. While having the source available is absolutely a good thing, there needs to be an easier way for new Linux users to install software. With so many different formats, some specific to some distributions, some to others, and so on, it's al
Re: (Score:3, Insightful)
You're making the somewhat dangerous assumption that a general policy of "one sizs fits all" is what the Linux user base both wants and needs - this is entirely incorrect.
For example, as an experienced L
Re:Ubuntu (Score:4, Informative)
You're not misinformed, although the author may still have a point of including it on the list of base distributions. There's a slew of Linux distributions based on Ubuntu. Still, you're right. The grandpappy of them all is Debian.
Here's a fairly comprehensive list [debianadmin.com] of these distributions.
Parent