Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
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 More

The Future of Packaging Software in Linux

Comments Filter:

  • The solution! (Score:5, Insightful)

    by Stormie ( 708 ) on Monday February 19, 2007 @12:43AM (#18064606) Homepage
    Why do I have a sneaking suspicion that the solution will be to create a sixth way of installing software, which will also not be widely accepted throughout the popular distributions?

    • Re: (Score:3, Informative)

      by tigerflag ( 648615 )
      PCLinuxOS uses a combination of Synaptic with RPMs from the PCLOS repository. Easiest package management I've ever used.

      • Re:The solution! (Score:5, Informative)

        by Max Littlemore ( 1001285 ) on Monday February 19, 2007 @01:19AM (#18064836)

        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 :-(

        • Re:The solution! (Score:5, Insightful)

          by M. Baranczak ( 726671 ) on Monday February 19, 2007 @02:15AM (#18065146)
          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.

          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.

          • Re: (Score:3, Insightful)

            by kripkenstein ( 913150 )

            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.

            Regarding the issue of dependencies, they might just be ignored completely for desktop applications (the focus of TFA). For server apps, you want t

            • Re: (Score:3, Informative)

              by penix1 ( 722987 )

              the simplest solution may be to just include all dependencies inside it.


              That's exactly how Microsoft tried to solve it and why their distributed software is huge. It also has led to problems of competing dlls which are often incompatible. If you think you have dependency problems now, just wait until you implement your idea! Imagine installing 16 applications each having a dependency on 16 different versions of the same lib.

              B.

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

            by nmb3000 ( 741169 ) on Monday February 19, 2007 @04:05AM (#18065672) 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.

            • Re: (Score:3, Informative)

              by petermgreen ( 876956 )
              MSIs are one of the best ideas for Windows in a while
              note that MSIs are nothing new, office was using that system (with a stub exe to make sure the microsoft installer was installed first) from office 2000 onwards and i think win2k shipped with it as standard.

              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.
              It is certainly a

            • Re:The solution! (Score:5, Insightful)

              by mrsbrisby ( 60242 ) on Monday February 19, 2007 @09:40AM (#18067166) Homepage

              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
              Now my daughter just received a "game" on Windows- brand new (2007) game that insisted on running in some "compatability" mode in Windows, and in a resolution that her LCD display couldn't cope with. The fact is that Windows users have run into this problem attempting to install software that isn't for their particular operating system, and failed on the Internet for a few hours. They just assume that Linux users have run into the same problem.

              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.

              This is also one reason people are willing to pay for an operating system that has a standardized and dependable way of doing things.
              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.

              Microsoft even released the WiX toolkit that allows anyone to create MSI installer packages.
              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.

              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.

              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.

              Instead you have a fully scriptable installer that's transaction-based and has near 100% support coverage.
              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.

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

              • Re: (Score:3, Funny)

                by ElleyKitten ( 715519 )

                Nobody is willing to pay for Windows
                I actually know a guy who purchased a brand-new copy of Vista for the computer he just built. Of course, he also unplugged all his fans when he was afraid that his power supply wasn't strong enough, so he's not exactly bright.

              • Re: (Score:3, Interesting)

                by _xeno_ ( 155264 )

                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 InstallS

        • Re: (Score:3, Interesting)

          by Anonymous Coward
          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 appre

    • Re:The solution! (Score:4, Funny)

      by SnowZero ( 92219 ) on Monday February 19, 2007 @12:49AM (#18064634)
      Don't worry, a seventh way will come along to wrap those first six which don't solve the problem, and it will be the ultimate meta-universal generic packaging system.

    • How about we take the easy way out? (Score:4, Interesting)

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

      • Re:How about we take the easy way out? (Score:5, Informative)

        by QuantumG ( 50515 ) * <qg@biodome.org> on Monday February 19, 2007 @01:43AM (#18064986) Homepage Journal
        Apt rules, shame about dpkg. Even bigger shame that apt is built on dpkg, eh?

        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.

        • You want "checkinstall". (Score:5, Informative)

          by khasim ( 1285 ) <brandioch.conner@gmail.com> on Monday February 19, 2007 @01:55AM (#18065054)

          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.

          Checkinstall http://www.debian-administration.org/articles/147 [debian-adm...ration.org]

          It's not the answer to all issues regarding installing from source ... but it does handle some of them.

          What really depresses me is that debs, dpkg and apt, that's about the best anyone has done.

          Any suggestions on what would make them even better?

      • Re: (Score:3, Informative)

        by seifried ( 12921 )

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

        by wizrd_nml ( 661928 ) on Monday February 19, 2007 @01:58AM (#18065064) Homepage

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

        • Re: (Score:3, Interesting)

          by dosquatch ( 924618 )

          ...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: (Score:3, Insightful)

        by LesFerg ( 452838 )
        You left out the parts that usually alienate new users;
        - 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: (Score:3, Insightful)

        by ploss ( 860589 )
        #10 - The ability for 3rd parties to create their own packages that have the same advantages as being in the repository. For example, I currently download xyz from SourceForge as a .deb, and have it install. Great. Why not provide some notification of a new version, like a link to an RSS feed inside the package file that is checked on every apt-get update? Why not list it in synaptic, adept, yumex, etc.? Also, make it easy for the developer.

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

        by wordisms ( 624668 ) on Monday February 19, 2007 @02:18AM (#18065150)
        Dude, until I can click on setup.exe, and it just works, and then there is an "Unistall Program" menu in the program folder on the program menu... I just don't have the time. I've used all 5 methods, and they are great for server management, but for general desktop use, people need click and run. Maybe CNR will take off.

        • Re: (Score:3, Insightful)

          by Chandon Seldon ( 43083 )

          Why is there this obsession with the awful Windows package system? Have you legitimately used a repository-based system with a GUI?

          Setup.exe + an Uninstall menu item is strictly worse than, say, the way packages work in Ubuntu. If you want to just distribute a package file and have the user double click to install, that works great. But... there's also a giant fully-supported package repository.

          I guess it basically comes down to one thing: As they would say on Fark.com... "No you can't have Linux be an ex

          • Re: (Score:3, Insightful)

            by davmoo ( 63521 )
            Why is there this obsession with the awful Windows package system?

            Because my 72 year old mother can, and does, install programs herself in Windows. If it requires anything more complex than "double click on setup.exe" or "double click on the program icon when you save it", you've lost her completely and I have to tunnel in to her machine or make a 125 mile drive.

            In the course of my work, I use Mandriva, Redhat, and Slackware distributions (I have never been able to get everyone elses' darling Ubuntu to ins

            • Re: (Score:3, Insightful)

              by burner ( 8666 )
              Sure, she can do the install, but what about getting updates and bug and security fixes? And what of spyware?

              I much prefer (as do my sister and mother) the simplicity of going to the Applications menu and clicking the entry for "Add/Remove...". You can browse around or search for a particular program by type or name. Click a checkbox, click OK, it's installed, unclick a checkbox, click OK, it's gone from your computer.

      • Re: (Score:3, Interesting)

        by Blakey Rat ( 99501 )
        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 ha

  • Applications Packages (Score:5, Interesting)

    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: (Score:2)

      by SnowZero ( 92219 )
      As does clicking on a checkbox [nongnu.org]. Seriously, I don't need it to be any easier.

      What we do need now are better guides telling people what they need to install for a given problem, since the link from task to program/package name is not always obvious. I know I can use google for that, but a more centralized and guided way would be nice for less technical people. That's why I think that click-n-run [linspire.com] has its place.

      • Re:Applications Packages (Score:5, Insightful)

        by AKAImBatman ( 238306 ) * <[moc.liamg] [ta] [namtabmiaka]> on Monday February 19, 2007 @01:13AM (#18064790) Homepage Journal

        As does clicking on a checkbox. Seriously, I don't need it to be any easier.

        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!
        • Well, I'd have to say that with most software projects, they provide a makefile. Yes, I know that it's a little bit steeper of a learning curve, but come on, it's not THAT much more work. Now, if the user is not savvy enough to go through the make process (which is usually only 2 commands long), then I don't think that they should be installing that stuff anyways. Just think, the stuff that's in the repositories are the packages least likely to cause problems with the installation. I've found most every
    • Yes, I would love to see the OS X install methodology on more systems. I dunno what else to say, just that there are at least two people out there who think it's a good idea.

    • Re:Applications Packages (Score:5, Insightful)

      by croddy ( 659025 ) on Monday February 19, 2007 @12:58AM (#18064702)

      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.

      • Re: (Score:3, Insightful)

        by value_added ( 719364 )
        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.

        Reading the above (which, incidentally, is little different than the traditional Windows ecosystem) raises the question whether this defines what end users demand and expect of package management, which is that they can install anything and everything when and how and from wherever the

      • Re: (Score:3, Insightful)

        by bcrowell ( 177657 )

        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.
        In addition to the reasons you mention, there are at least two other reasons why it's a poor fit to Linux.

        One reason is that the typical Linux user is running 90+% OSS, while the typical Mac user is running 90+% proprietary software. The individuals and organizations distributing OSS are generally giving it away f

    • Re: (Score:3, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

      • A total load of bullshit, and here's why (Score:5, Informative)

        by Overly Critical Guy ( 663429 ) on Monday February 19, 2007 @01:59AM (#18065068)
        My favorite thing in package discussions is when someone with an agenda towards a particular implementation writes out a list of steps. The alternative is always padded with extra steps to make it more difficult-looking while their favored implementation is reduced to look squeaky clean and easy.

        You padded the Mac list with the following:
        • "Open disk image that contains the program." - DMGs are auto-mounted by Safari.
        • "Open Applications folder." - There's already an Applications shortcut on the Finder, so you just drag to that when the disk image window automatically opens.
        • "Create new icon in dock." - The fuck? You don't have to do this
        • "Have to recheck the site periodically to check for a update for a specific program" - Bullshit. This doesn't even have to do with package management, and it's an OS X convention for apps to auto-check for updates when they're run. You don't have to recheck any websites.

        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.

    • not really (Score:3, Interesting)

      by ArbitraryConstant ( 763964 )
      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, instal

  • The five ways (Score:4, Informative)

    by Harmonious Botch ( 921977 ) * on Monday February 19, 2007 @12:46AM (#18064616) Homepage Journal
    For those who don't TFA: There are currently at least 5 popular ways of doing it:
    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.

    • Re: (Score:2)

      by rm999 ( 775449 )
      It seems to me that this way is the best method for 90% of people (I'm a Linux n00b):
      4) Installing from distribution-independent binaries (most proprietary software is delivered this way),

      I apologize if the answer to this is obvious, but why isn't everything packaged that way?

      • Re: (Score:2)

        by CaptnMArk ( 9003 )
        Installation must NOT involve any execution of the code from the package.

        If it does it is likely that uninstalls and upgrades will not work reliably.

    • 5) Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.

      There are very good reasons why autopackage hasn't been accepted. It's hopelessly broken [gentoo.org]. Anyway, asking for one unified package format is like asking for exactly one Linux distro; it betrays a fundamental misunderstanding of the OSS community.

  • I prefer a discreet brown paper bag...

  • Nonissue (Score:2, Insightful)

    by eklitzke ( 873155 )
    The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code. Any software that is even moderately popular will be packaged by volunteers. If I need some software that isn't already packaged for me, I grab the source code and compile it. If it's something I plan on sharing with other people, I'll write a spec file and distribute the RPM I build.

    I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen. De

    • Re:Nonissue (Score:5, Insightful)

      by rsmith-mac ( 639075 ) on Monday February 19, 2007 @12:58AM (#18064696)

      I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen

      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.

      • Re: (Score:2)

        by spitzak ( 4019 )
        Though I don't agree with him, he quite clearly said he believed people who know how to compile the code would compile any popular program for each package format. He did not say that everybody would compile from source. Read a little more carefully next time.

      • Re: (Score:2, Interesting)

        by croddy ( 659025 )
        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.
      • Who rated this insightful? What does this have to do with "making a dent in the market"? Nothing prevents a hardware vendor from choosing a distro and sticking with it. Who cares if there are 12 other distros out there? The customer wants Firefox and OO to run, and they will run. GNU/Linux already has the best packaging system ever for an inexperienced user (deb), and any vendor is free to support it, or to relegate the support to a specialist company.

      • Re: (Score:2, Insightful)

        by Lord Kano ( 13027 )
        Either Linux is going to be a OS for users, or a OS for geeks.

        Exactamundo!

        Maybe this makes me a heretic, but I don't think that Linux should ever try to become a mainstream user OS. A part of the allure of linux is that it is hard. The learning curve makes users feel like they've achieved something by becoming proficient.

        If you made a distro, how would you prefer to spend your time? Would you rather deal with "XYZ_lib_devel is out of date, we need a package for the new version." or "How do I get AIM, ICQ a

      • Re:Nonissue (Score:5, Insightful)

        by zzatz ( 965857 ) on Monday February 19, 2007 @02:52AM (#18065314)
        "...never make a significant dent in the Microsoft+Apple consumer desktop market."

        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.

      • Re: (Score:3, Insightful)

        by account_deleted ( 4530225 )
        Comment removed based on user account deletion

    • Re: (Score:3, Insightful)

      by oberondarksoul ( 723118 )

      The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code... If I need some software that isn't already packaged for me, I grab the source code and compile it.

      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

  • RPM gets a nod but.... (Score:4, Insightful)

    by westyvw ( 653833 ) on Monday February 19, 2007 @12:59AM (#18064706)
    Debian and Ubuntu don't even get a mention on what they DO use? This article makes it sound like RPM is THE package management system. Give me a break, at least a mention that a similar package approach (and more successful IMHO) is used by the Debian etc.

  • Hasn't explored other packaging methods (Score:5, Informative)

    by shermozle ( 126249 ) on Monday February 19, 2007 @12:59AM (#18064708) Homepage
    (while discussing RPM)

    Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it.
    What that means is he hasn't used any other packaging formats. Common mistake that people think RPM is somehow "best" because it's used by a few distros. Do some searches for "circular dependency RPM" to see why that's just not true.

    • Re:Hasn't explored other packaging methods (Score:5, Informative)

      by DoubleRing ( 908390 ) on Monday February 19, 2007 @01:21AM (#18064852)
      Hear hear! I have mod points, but I'd rather post.

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

      • Re:Hasn't explored other packaging methods (Score:4, Informative)

        by Alioth ( 221270 ) <no@spam> on Monday February 19, 2007 @03:59AM (#18065646) Journal
        Circular dependency hell?

        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.

    • Re: (Score:2)

      by Soko ( 17987 )
      What that means is he hasn't used any other packaging formats. Common mistake that people think RPM is somehow "best" because it's used by a few distros. Do some searches for "circular dependency RPM" to see why that's just not true.

      The vast majority of people who aren't Linux geeks, or rely on a commercially supported distro get RedHat or Suse. Guess what package format they use?

      I agree that RPM isn't the best, but in an enterprise setting it's what you get. I'm hoping Canonical can make inroads to that ma

    • Re: (Score:3, Insightful)

      by cortana ( 588495 )
      Not to mention https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=119185 [redhat.com] which is still not really fixed.

  • goddammit (Score:5, Insightful)

    by scenestar ( 828656 ) on Monday February 19, 2007 @01:00AM (#18064712) Homepage Journal
    We have apt and *.debs

    I'm not in the mood for a holy war right now, but for fucks sake, Debian perfected package management a decade ago.

    • Re: (Score:2)

      by croddy ( 659025 )
      Don't forget about Debconf! The ability of the OS to centrally manage configuration for a variety of applications is one of the most important advantages of the Debian style of package management.

    • Re: (Score:3, Informative)

      by Salsaman ( 141471 )
      Well, the system may be perfect, but the packagers certainly are not. It's next to impossible to get a new package into their repositories (I've been asking for over 2 years now !), which is I why I have to rely on the good people at getdeb.net (Ubuntu), and debian-multimedia.org (debian).

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

  • They don't care about the file ext., fix the list (Score:3)

    by BillX ( 307153 ) on Monday February 19, 2007 @01:14AM (#18064808) Homepage
    Well, they all involve a long list of available programs you could choose to install (plus dependencies, etc.) Granted, some have meta-package choices, e.g. "workstation collection", but past that, it comes down to a dumfounding-to-newbies long list of packages whose developers tried really hard to come up with a clever acronym, name it after their favorite band/old Norse god/tropical fish's Latin name, etc., rather than something that gives some clue as to what the program actually does. Personally, probably the most off-putting thing my first time installing a Linux distro (besides hardware configuration, which has gotten much better since then) was a package selection dialog with thousands of entries like:

    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, .deb, or what-have-you (provided the installation doesn't barf)

  • sigh... (Score:3, Insightful)

    by element-o.p. ( 939033 ) on Monday February 19, 2007 @01:53AM (#18065038) Homepage
    Why, oh why does everyone always have to gripe that "distro x doesn't do things the same way as distro y?"

    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)

    by NeuroManson ( 214835 ) on Monday February 19, 2007 @01:55AM (#18065046) Homepage
    Look. If you want mainstream acceptance, then appeal to the mainstream. THAT is what will determine the best distro.

    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)

    by aero6dof ( 415422 ) <aero6dof@yahoo.com> on Monday February 19, 2007 @02:23AM (#18065174) Homepage
    I'm only exaggerating a little here, but no one really cares about the packaging format per se. They care that the can find, download, install, and run a package without hassles. Most formats take care of the mechanics of that process, but still need a community of people to track down and fix issues - mostly inter-package issues. Rpm and deb both have that kind of community behind them (both with sub-groups). If there is any technology to be improved here, it should be making package repositories better and reducing the workload of the supporting communities.

Slashdot Top Deals

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Close