Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Software Linux

The Future of Packaging Software in Linux 595

Posted by Zonk
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 Future of Packaging Software in Linux

Comments Filter:
  • by SultanCemil (722533) on Monday February 19, 2007 @12:44AM (#18064612)
    If only major linux distros would use Application Packages like OS X, the world would be a better place.

    Seriously, drag-n-drop installation rocks.

  • Re:The solution! (Score:1, Interesting)

    by Anonymous Coward on Monday February 19, 2007 @12:49AM (#18064636)
    Fat binary; all dependencies complied into it.
  • by Whiney Mac Fanboy (963289) * <whineymacfanboy@gmail.com> on Monday February 19, 2007 @12:54AM (#18064672) Homepage Journal
    If only OS X users would stop whining about OS X in linux stories, the world would be a better place.

    Seriously, being able to read a linux story without inevitable, (innaccurate & irrelevant) OS X comparisons would rock.
  • by khasim (1285) <brandioch.conner@gmail.com> on Monday February 19, 2007 @12:57AM (#18064692)
    And that is ... define the requirements that the next generation package manager should have.

    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)

    by PornMaster (749461) on Monday February 19, 2007 @01:01AM (#18064726) Homepage
    The hard part, as I see it, is dependency management for upgrading software.

    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)

    by ArbitraryConstant (763964) on Monday February 19, 2007 @01:04AM (#18064746) Homepage
    The problem is not that everyone is willing to accept a solution that sucks, the problem is that the current solution of integrated package management rocks.

    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)

    by croddy (659025) on Monday February 19, 2007 @01:12AM (#18064782)
    You may want to read this excellent essay, entitled Linux is not Windows [oneandoneis2.org]. I think it will offer you some valuable perspective on the issues you're addressing.
  • Hell Yeah! (Score:1, Interesting)

    by Anonymous Coward on Monday February 19, 2007 @01:17AM (#18064824)
    Absolutely right, never mind the inconsistencies as they don't affect the normal user.

    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).
  • by Anonymous Coward on Monday February 19, 2007 @01:37AM (#18064956)
    like when I was trying to create a deb for personal use (and creating it the right way, not this checkinstall bs) I got hassled by ubuntu universe devs why do I want to create such a package and I should just be happy with the version they provide. I told them why (the version back then, and the one that still stands still doesnt support my HW, only the cvs version does, I understand why they dont include it, but I was merely asking for advice) and they ripped me apart telling me to sell my hardware or get my money back on it somehow or to just wait and stop bitching and be happy with what's in the repository.

    In the end the debian folks were much kinder, and helped me out.
  • by srealm (157581) <prez.goth@net> on Monday February 19, 2007 @02:09AM (#18065118) Homepage
    One more thing.

    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)

    by Anonymous Coward on Monday February 19, 2007 @02:46AM (#18065284)
    A great idea??? Are you serious?

    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.
  • by MrZaius (321037) on Monday February 19, 2007 @02:49AM (#18065298) Homepage
    To put it all in perspective, on my 400mhz g3 q/196mb ram, OOo in Linux w/gnome runs at a comparable speed to neooffice in OSX.
  • by be-fan (61476) on Monday February 19, 2007 @03:17AM (#18065430)
    There are substantial deficiencies with OS X-style packages, which would only be amplified in the Linux world. In general, OS X packages have to bundle libraries that are not included by default in the OS. This leads to anywhere from a little to a lot of wasted disk space and memory. The problem is limited in OS X, because there is a standard set of frameworks Apple ships with, but this is not true on Linux. As a result, app bundles would have to include things like GNOME as well.
  • by Anonymous Coward on Monday February 19, 2007 @03:20AM (#18065456)
    Installing software that's not in the repository is hell on earth for a user?

    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.
  • by be-fan (61476) on Monday February 19, 2007 @03:21AM (#18065466)
    There is also another strength of package managers that the app-bundle system lacks. In OS X, apps will pester you to update them. Colloquy, which releases several times a month, gets really annoying in this regard. In OS X, apps have to do this because there is no way to update all apps automatically. A package-managed system doesn't have this problem.
  • by dosquatch (924618) on Monday February 19, 2007 @03:46AM (#18065580) Journal

    ...and it must do all of this without telling me what it's doing, because I don't care what it does as long as the software then works.

    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)

    by nmb3000 (741169) <nmb3000@that-google-mail-site.com> on Monday February 19, 2007 @04:05AM (#18065672) Homepage Journal
    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.

    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.
  • by Blakey Rat (99501) on Monday February 19, 2007 @08:33AM (#18066754)
    No.

    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)

    by _xeno_ (155264) on Monday February 19, 2007 @10:39AM (#18067604) Homepage Journal

    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.

    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...

    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.
    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.

    Most of those EXEs are actually MSIs wrapped with a stub installer that can install the Windows Installer if it's missing.

    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.

    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.)

    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.

    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)

    by Anonymous Coward on Monday February 19, 2007 @11:14AM (#18067918)

    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)

    by AeroIllini (726211) <aeroillini@@@gmail...com> on Monday February 19, 2007 @03:59PM (#18072096)
    Ok, so the binary package capability of Gentoo may not be completely unused, but it is used sparsely, if that. A very few select programs have binary equivalents (OpenOffice, Firefox, and Azureus come to mind), but what I think the GP is looking for is a way to specify "all binary, all the time" as a build option. I'm certainly looking for that. Combine that option with the newly-introduced graphical installer, and voila! Gentoo can be used as a Grandma System, too.

    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 /etc/portage/package.keywords.

    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?

The tree of research must from time to time be refreshed with the blood of bean counters. -- Alan Kay

Working...