Slashdot Mirror


How to Make Easy-to-Package Software, Part 2

jmmv writes "A month ago (more or less), the first part of the Making packager-friendly software was published and announced here; it seemed to be warmly accepted by the community. Now it's the turn for the second (and last) part, which has just seen the light. It deals with problems caused by recursive dependencies, configuration file handling, unprivileged builds, the make utility, build infrastructure oddities and some notes about code portability. Of course, these are just suggestions to try to make the life of packagers a bit simpler; you can just ignore them if you want to. I hope it will be of interest and that future versions of your creations are easier to package. Thanks!"

13 comments

  1. Nethack by biryokumaru · · Score: 1

    I hope the nethack dev team reads this! X|

    --
    When you're afraid to download music illegally in your own home, then the terrorists have won!
  2. Wrong link by Anonymous Coward · · Score: 0

    The link for the first article incorrectly points to the second article - it should point here.

  3. Installers by Umbral+Blot · · Score: 4, Insightful

    You have to admit, no matter how much you like Linux, that both windows and mac have done a much better job with their installers. I can whip up an installer in a few minutes on windows that I am confident will work on everyone's machine, but this is unfortunately not true in Linux.

    1. Re:Installers by davegaramond · · Score: 0, Troll

      Well, Windows is much worse than Linux. Package management (RPM, dpkg, etc) is much better than "installers", which are basically programs to copy files manually into the filesystem. How old-fashioned.

    2. Re:Installers by ahsect8 · · Score: 1

      > which are basically programs to copy files > manually into the filesystem But they can do so much more! It's a mysterious binary executable. It can do anything it wants...

    3. Re:Installers by 0racle · · Score: 2, Funny

      Old fashioned? Thats the whole reason I run Slackware.

      --
      "I use a Mac because I'm just better than you are."
    4. Re:Installers by jatreuman · · Score: 2, Interesting

      This really isn't any surprise when you consider how varying Linux distros can be, and how similiar installations of Windows are. In practice however, a binary will work on any Linux distro of the same architecture provided the required libraries are available, which makes this a dependency issue. Windows avoids this by providing many commonly used functions as part of a base install, while Linux distros make these (and many more) optional. If Microsoft doesn't provide a needed function, the programmer either codes it themselves or includes a third party library as part of the installer. Of course, this has it's disadvantages:

      • A bloated base operating system with libraries you may not need (though in practice, many of the built in applications that your average joe uses depend on them), and
      • programmers waste time reimplementing functions that Microsoft does not provide, or
      • installers install DLLs globally and you have DLL Hell, or
      • installers waste disk space and memory by installing DLLs in their application directory.

      The last group could be avoided by installing DLLs globally with versioned filenames, but I guess that would be too unixy. :P

      The fact that Windows doesn't provide an installation system is also a big minus. For example, installing firefox with flash support on Gentoo:

      • emerge firefox netscape-flash

      And on Windows:

      • Run MSIE
      • Google for firefox, because you don't have the URI memorized
      • Download installer
      • Run installer
      • Go through installation wizard (3 steps minimum, IIRC)
      • Run firefox
      • Google for macromedia flash
      • Download installer
      • Run installer
      • Go through installation process (which I can't remember)
      • Restart firefox

      I don't know about you, but I think the Gentoo way is easier. Sure it'll pull in dependencies, and spend a good while building it all. But apt, and other binary packaging systems I'm not familiar with, can be just as good, and in most cases will be faster even when grabbing dependencies.

    5. Re:Installers by davegaramond · · Score: 1

      It can do anything it wants...

      Which makes me like it less. Things will break due to faulty or stupid installers.

  4. Yes but what will your installer *break*? by leonbrooks · · Score: 3, Insightful

    For a self-contained YAKoSoSBP<*>, no worries, but for anything serious you have to futz around lots to avoid DLL collisions and registry slapdown games. On Linux or BSD, I just put in the dependencies and let URPMI/yum/apt/YAST sort it out. Different versions of shared libraries are delighted to coexist, BoC you don't need to do that, see below.

    Anyway, why do you need to ship an installer at all, isn't the OS supposed to provide that kind of plumbing? And what happens when the user gets to WinCE on ARM or something like that? I can post a .src.rpm for people whose distros or architectures I haven't explicitly packaged for, can you? The .src.rpm also allows seamless integration with systems running on odd versions of shardd libraries, one simply does a wone-liner (or one-click) rebuild of the offending .src.rpm and viola, all dependencies solved.

    <*> YAKoSoSBP == Yet Another Kind of Solitaire or Sliding Block Puzzle

    --
    Got time? Spend some of it coding or testing
  5. People like Mandrake, sorry, Mandriva... by leonbrooks · · Score: 1

    ...have well-written, comprehensive, low-level instructions for building packages properly, but it's nice to see a well-written piece which is a bit more "meta" and general than that as well.

    The instructions even work with their "Stoned Penguin" LoopyEdition2005 release. (-:

    --
    Got time? Spend some of it coding or testing
  6. DLL hell is a thing of the past... by beejaymumbling · · Score: 1

    ...mostly.

    I've built dozens of installers for Windows apps and even distributed them to a variety of customers.

    The only problem I've found is that not everyone has the dependencies installed--for example, not everyone has .NET at this point--but I can easily point them to things like that. There tend to be only one or two dependencies at maximum.

    On linux, there are so many different libraries required to run any app that doesn't run in the console. To actually BUILD something can be an amazing amount of work. It took me several hours to set up the build environment for OOo 2 beta on ubuntu.

    "DLL hell" is a much worse problem on Linux, because Linux gives many many more choices than Windows. Whether this is good or bad is in the eyes of the observer.

    1. Re:DLL hell is a thing of the past... by Anonymous Coward · · Score: 0

      DLL hell is a thing of the past

      In your world maybe, but some of us are still waiting for the official EOL for the .NET framework, which has the worst DLL Hell I have yet encountered, Windows or otherwise.

      "DLL hell" is a much worse problem on Linux, because Linux gives many many more choices than Windows.

      If you mean it makes creating a DLL Hell possible, sure, but why would anyone want to create one? As long as people stick to the ld.so guidelines / naming conventions, there isn't one, because libblah.so.1 will always be libblah.so.1, and will never be overwritten by libblah.so.8 (or even worse, the other way around as often happens on Windows).

      If on the other hand you mean "taking something completely different than DLL Hell and calling it DLL Hell just to spread fud", please use a different word to avoid confusion.