Slashdot Mirror


How to Make Easy-to-Package Linux Software

jmmv writes "The packages in any Linux distribution (or other operating systems) are a master piece to let the user install any program he wishes as painlessly as possible. However, the creation of these packages is not always free of problems. Usually, the packager finds that the program he wants to package suffers from a series of pitfalls - either conceptual or related to portability - that make the packaging task harder than usual. This is why I decided to write an article (published at ONLamp.com) summarizing these problems and proposing several solutions to each of them, aiming to make the life of the packager simpler. I hope it to be of interest to free software developers and also hope that they understand some of the issues and try to fix them in their creations."

8 of 52 comments (clear)

  1. Re:How to properly package for linux by keesh · · Score: 3, Interesting

    Oh, brilliant idea. Force everyone to run arbitrary shell scripts before they can even unpack your package. At least with a tarball you can extract it and check the contents without having to run any untrusted package-supplied code.

  2. Re:How to properly package for linux by Anonymous Coward · · Score: 1, Interesting

    Because of course everyone uses x86, no-one uses any apps written in C++, there are no such things as optional dependencies, every package distributer can be trusted, and every distribution builds software in exactly the same way with exactly the same library versions.

    Oh, wait...

  3. Third solution to Automatic Decisions by Papineau · · Score: 3, Interesting

    The article is missing a third solution to the Automatic Decisions solutions: gracefully handle at runtime the absence of a (soft) dependancy.

    What I mean is automatically enable all options which are available at build time, but don't hard link to them (use dlopen(3) or somesuch instead), so the same binary package would work in the presence or absence of such dependancies.

    Of course, without the runtime dependancies, some options won't be available, but it's better to do it that way than to force everybody to download libfoo and libbar to satisfy an optional dependancy, or to arbitrarily disable some options (which will only be available to people building from source, not those using a package. You want your software to be useful, right?).

    1. Re:Third solution to Automatic Decisions by Anonymous Coward · · Score: 1, Interesting

      are there any decent wrappers for dlopen() that make it more like linking against a .so ? I HATE having to munge function names etc.

      The Amiga allowed you to dynamically load libraries, yet when you were coding, late bound .library (unix: like dlopened() .so) function calls looked the same as static link .lib (unix: .a) function calls through macro/#pragma magic hidden in the .h file for the library.

  4. Re:How to properly package for linux by keesh · · Score: 2, Interesting

    LSB is a silly RedHatism. Remember, if you want to be LSB compliant, X11 support is mandatory.

  5. Re:There Should Be a Self-Installing Binary by chromatic · · Score: 3, Interesting

    Is it simple or obvious?

    64-bit? 32-bit? With debugging symbols? Without debugging symbols? Statically-linked? Dynamically linked? Which level of optimization? Which kernel? Which compiler? Which glibc? Which processor family? Which instruction set within a processor family? What options have I missed?

    How big is this one self-installing binary you want someone else to create for you?

  6. Re:There Should Be a Self-Installing Binary by Anonymous Coward · · Score: 1, Interesting

    It is simple AND obvious. If you want software to be usable, it needs to be flexible. By flexible, it needs to appeal to novice users AND power users. Try this: 32-bit, no debugging symbols, link statically or include your libraries (its worth the disk space to provide an easy uninstall), optimize -O1 (basic optimization - nothing fancy that could affect how registers are used), compile for a 3-4 year old intel-compatible processor (P2 or P3 by now), and unless you're writing a device driver leave the kernel out of it. That should catch a good number of users. Provide source so smart people can do what they want, but don't leave out the people who don't know as much as you.

  7. Simple... by agraupe · · Score: 3, Interesting
    Appfolders, like in OS X, for the very simple method. This causes overlap in dependencies, but it will always work. This is the easiest system to deal with, IMO. There can be a simple tar-ball, or self-extracting archive.

    Next, there's distro-based package systems like apt and portage. These work very well, as dependency control is automatic, and it is made to work with your distro specifically.

    The third option, which is used by (I think, but am not sure) Loki Installer, and such programs, is to install the binaries, but leave you on your own to deal with dependencies. As long as you make sure the dependencies are easy to obtain, this is one of the best options for those without apt or a similar system. You could even, with GPL software, create your own installer for any dependancies, should you choose.

    Why not Autopackage? Because it seems like a format that is, at best, a poor substitute for a package system like apt. The simplest solution, considering how much disk space is available on modern machines, is the folder concept like OS X. Very simple, and incredibly easy to remove programs.