9

The source code in not open or free, so compilation at installation is not an option. So far I have seen developers that:

  • provide a tar.gz file and it is up to user to uncompress in suitable location.
  • provide a .tar.gz with an install.sh script to run a basic installer, possibly even prompting user for install options.
  • provide RPM and/or deb files, allowing user to continue using the native package management tools they are familiar with to install/upgrade/uninstall.

Would like to support the most number of Linux distributions, make users' lives as easy as possible, and yet maintain as little build/packaging/installer infrastructure as possible too.

Looking for recommendations on how to package my software.

Improve this question
0

4 Answers 4

Reset to default
19

I see two ways to look at it.

One is to target the most popular Linuxes, providing native packages for each, delivering packages in popularity order. A few years ago, that meant providing RPMs for Red Hat type Linuxes first, then as time permitted rebuilding the source RPM for each less-popular RPM-based Linux. This is why, say, the Mandriva RPM is often a bit older than the Red Hat or SuSE RPM. With Ubuntu being so popular these past few years, though, you might want to start with .deb and add RPM later.

The other is to try to target all Linuxes at once, which is what those providing binary tarballs are attempting. I really dislike this option, as a sysadmin and end user. Such tarballs scatter files all over the system you unpack them on, and there's no option later for niceties like uninstall, package verification, intelligent upgrades, etc.

You can try a mixed approach: native packages for the most popular Linuxes, plus binary tarballs for oddball Linuxes and old-school sysadmins who don't like package managers for whatever reason.

Improve this answer
4
  • This is almost exactly the approach I have taken so far - started with RPM for Redhat/Fedora/CentOS, now providing Ubuntu/Debian .deb files, but hadn't yet decided if making a tar.gz would still be useful and needed. Sounds like it would be good for allowing users with less popular distros to at least get the software working themselves rather than not even having an option. Thanks.
    – Mike Gray
    Aug 16, 2010 at 14:27
  • 2
    Making a portable binary tarball may be a lot more work than you imagine. Just one potential trap is that the g++ ABI has changed several times over the years, so you may have to ship binary versions of any C++ libraries you use rather than use the platform versions to achieve wide enough compatibility. This is one reason a single binary RPM doesn't install and run everywhere. There just seems to be a cultural acceptance of this fact with RPM, though, whereas tarballs -- probably because they're an ancient standard -- are expected to work everywhere.
    – Warren Young
    Aug 16, 2010 at 14:37
  • I have seen the mix approach to be best one: that you can reach a lot of people and the effort is not that much.
    – Hugo
    Aug 17, 2010 at 19:13
  • Making a simple, binary tarball is still good. Specially if that tarball stores all game files at one self-contained directory. It will allow some users to unpack and run it without installing; and it will also make the life easier for other distros (like Gentoo, Arch, and so on), because it will be easier for them to unpack/repackage that tarball.
    – Denilson Sá Maia
    Aug 17, 2010 at 23:24
4

Whatever you do, make sure you include a "support script" that allows you to collect as much information as possible on the target system for troubleshooting errors. I guarantee you will run into issues and debugging things the customer says versus reality is often very different.

Improve this answer
0

My preference is always for a package (rpm|deb etc.). Depending on the nature of the software it may be worth targeting packages for specific distros (rhel/centos etc.), but you'll probably never be able to roll enough packages for everyone.

Install scripts can be ok, depending on the script. For me, the most important thing with non packaged software is that it's easy to install it at a location I choose.

Improve this answer
0

Games tend to use an installer (formerly Loki Installer, nowadays MojoSetup), which installs a game cleanly into a prefix and handles stuff like icons.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.