Slashdot Mirror


The Future of Packaging Software in Linux

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

4 of 595 comments (clear)

  1. mod 0p by Anonymous Coward · · Score: -1, Troll
  2. packaging issues by Anonymous Coward · · Score: -1, Troll

    All the packaging formats and ideas they're built on can all suffer from the same crippling flaw: the packagers themselves. You've got some user1 on distroA installing rpms left and right from the official repos/cd/dvd and even from the 'uber popular' 3rd party repos without a hitch. You've got user2 on distroB installing debs left and right from official repos/cd/dvd and even from 'uber popular' 3rd party repos without a hitch. You've got user3 on distroC installing slackware tgz's left and right... You get the idea.

    The fun begins when:

    (A) some twat at the uber popular repo packages up some funky, little-known software on his testbed that's got bleeding-edge versions of popular libs installed, and like a twat, doesn't think about who is installing that package once its up on the repo. Suddenly users are back in dependency hell (which exists on every single package-type, don't be ignorant and blame it on rh just because they're popular; even slackware experiences it when your newly installed package segfaults or can't find some .so out of the fuckin gate).

    (B) some twat packager packaging up stuff for the distro itself (official repo stuff) forgets he's got some uber new package of some important lib installed and makes a dozen packages that require it specifically, THEN puts said bleeding-edge package in the repo (think gnome/gtk here for the huge myriad of dumb-shitted dependencies). Now you've got users who, if they upgrade before its caught, break the entire system, or if their automated package update program (yum, apt, slapt, etc) is smart, it says "whoa boy, some twat fuckwit has screwed up here, and this old lib is conflicting with this bleeding-edge lib and it looks like half your system needs the old and the half needs the new version. U B FUCKT."

    (C) You try to install packageX that was packaged up only for Fedora. You're user3 on distroC (slackware-based) and your libs and what not are not bleeding edge enough. PackageX was written in a fedora environment, and the author makes use of the special features (or does he?) in those bleeding edge libs, and so trying to compile it for slack becomes a fucking nightmare that either requires you to come up with new packages for half the libs on your system, or patch the fuck out of PackageX, or tell the author what a dumb cunt he is (usually the last two are done in tandem).

    (D) You think you're badass by using an even more bleeding-edge repo (example: Dag), whose packages are (or used to be) built against retardedly bleeding-edge versions of critical libs, requiring the user to either hand-compile said bleeding-edge libs and install em elsewhere on the system and start down a retarded path to insanity when it all eventually breaks, or upgrade their old, critical libs with new bleeding-edge libs that break 12/13's of the system (then they jump on their blog and say how much dependency hell sucks and how much redhat sucks for allowing it to happen).

    Usually A & B don't happen much anymore, thank christ. D happens when one smart user gets some "desired" program to work on a popular distro using some bleeding-edge repo, then tells a bunch of twatnewbs on a forum somewhere about it, prompting a good number of them to bomb their installs. And because they're twatnewbs, they haven't got half a clue how to fix their bombed system, and with much yelling and screaming and general tom foolery about how "linux bloz yohz," they head back to windows, and then jump on their blog and tell the world about how linux has failed.

    C happens all too often for us non-fedora/debian/ubuntu users out there. But if you're not using a redhat/debian/gentoo derivative, you probably have a clue, and either realize it's not worth the effort, or you make a (usually) top-shelf package that "just works(tm)" and breaks nothing... and then keep it to yourself cuz you're fucking cool like that.

    My advice to new users of linux: stick to the fedora (simply because everything has a fucking fedora rpm for it, and any fedora rpm f

  3. There is a unified package format by ajs318 · · Score: 1, Troll

    There is a unified package format, and that is the source code tarball.

    People need to be disabused of the notion that there is anything bad about compiling on your own machine. Gentoo and FreeBSD prove that is not the case.

    --
    Je fume. Tu fumes. Nous fûmes!
  4. Re:The solution! by ichimunki · · Score: 0, Troll

    The idea of the post you're replying to was to package dependencies inside the application. That way, you can indeed install 16 applications each having a dependency on 16 different versions of the same library, with no problems whatsoever.

    In your example... every application for Mac OS X is entirely statically compiled? They don't even link to system libraries that one can reasonably assume an Mac OS X install has?

    --
    I do not have a signature