Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Software Linux

How to Make Easy-to-Package Linux Software 52

Posted by timothy from the easy-rocks dept.
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."
This discussion has been archived. No new comments can be posted.

How to Make Easy-to-Package Linux Software More

How to Make Easy-to-Package Linux Software

Comments Filter:

  • Avoid modifying published distfiles. (Score:3, Insightful)

    by keesh ( 202812 ) on Saturday April 02, 2005 @05:06PM (#12121481) Homepage
    "Avoid modifying published distfiles."

    Oh heck yes. The number of times I've been bitten by a few projects (yes mplayer guys, I mean you) doing this and breaking Gentoo's digest system...
  • What the hell else can I say?

    There should be a self-installing binary.

    Wow, it's so simple and so obvious.

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

      • Re:There Should Be a Self-Installing Binary (Score:1, Interesting)

        by Anonymous Coward
        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 kerne
        • Statically linked. Great. So now, when someone finds a security bug in the library, you not only have to update the library, you have to figure out all the programs that use that library statically and update them as well.

          Wonderful idea! I'm sure that'll make everything /much/ easier for end users.

          • Re:There Should Be a Self-Installing Binary (Score:1, Insightful)

            by Anonymous Coward
            Statically linked. Great. So now, when someone finds a security bug in the library, you not only have to update the library, you have to figure out all the programs that use that library statically and update them as well.

            Dynamically linked. Great. So now, when a new release of a library introduces a security bug, you automatically compromise all the programs that use that library.

            Hey, it cuts both ways.
    • I've got a 64bit PPC NetBSD self-installing package here that. Can you use it?

    • Re:There Should Be a Self-Installing Binary (Score:2, Funny)

      by Anonymous Coward
      There should be a self-installing binary.

      That's too much like Windows. If software is hard to write, it should be hard to install.

  • Third solution to Automatic Decisions (Score:4, Interesting)

    by Papineau ( 527159 ) on Saturday April 02, 2005 @06:18PM (#12121968) Homepage

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

    • Re:Third solution to Automatic Decisions (Score:1, Interesting)

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

      • Re:Third solution to Automatic Decisions (Score:3, Informative)

        by Anonymous Coward
        This is because amiga .library files were a bit like C++/COM objects: each library had a jumptable and base address. Jumptable entry offsets from the base address called LVOs (library vector offsets) were public and known. All library calls were indirected through the jumptable. So the compiler knew from the #pragma in the header to compile a call to, say, intuition.library/OpenWindow() or whatever (my amigaos zen is, uh, rusty, for some reason), to a jump to address IntuitionBase minus LVOOpenWindow, whi

      • Re:Third solution to Automatic Decisions (Score:4, Informative)

        by FooBarWidget ( 556006 ) on Sunday April 03, 2005 @08:46AM (#12125818)
        You may be interested in relaytool. See http://autopackage.org/ [autopackage.org] for info.

  • Simple... (Score:4, Interesting)

    by agraupe ( 769778 ) on Saturday April 02, 2005 @09:20PM (#12123191) Journal
    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.

    • Congratulations! You haven't got a clue what you are talking about. You clearly have no grasp of Linux packaging, what is involved, what is required, what is sensible, what autopackage is, what autopackage is good for, nor did you read the fucking article.
      • I'll admit that, but people who know more than me have come up with plenty of reasons that autopackage is a bad idea. The rest of my arguments are still valid.

  • This definately is a shortcomming in linux distros (Score:5, Insightful)

    by Stevyn ( 691306 ) on Sunday April 03, 2005 @12:47AM (#12124358)
    Take a look around. You either get a good method for a few outdated packages, or you get a great system that takes forever to compile packages. Obviously, I haven't dealt much with debian based distros and their magical apt-get, but the major distros like Suse, mandrake, and fedora are still RPM based. I think RPMs have really slowed down linux adoption due to dependency hell. I hope systems like autopackage can help things out.
    • Agreed. Red Hat made me want to dive into a river to rid myself of all of these dependency issues, and I was aged by the time X,KDE,Gnome,Firefox,Thunderbird, et al finished compiling on Gentoo. I've got high hopes for autopackage, but haven't used it yet. I think that it is obvious that the thing that is keeping linux off the desktop is the difficulty in installing software. RedHat (and other RPM distros) - if you want to have a completely nontechnical-user environment, you can't expect them to touch a
    • You either get a good method for a few outdated packages, or you get a great system that takes forever to compile packages.

      Compiling? Who's talking about compiling?

      Oh... it's Linux. You HAVE to compile. -.-

  • I frequently need to package software up for distribution, and have seem bith increadibly easy and next to impossable.

    Please please please do NOT make the build system more complex than the app being installed! Inside every 200 line monument to bogosity is a 10 line makefile trying to get out. I'm not kidding. I realise there are a few cases where it's justifiable, but those are a lot less common than people seem to think. When it's easier for a package maintainer to throw the makefiles away and copy in a

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close