Question

I have an application that I’ve written for Windows which I am porting to Linux (Ubuntu to be specific). The problem is that I have always just used Linux, never really developed for it. More specifically, I dont understand the fundamental layout of the system. For example, where should I install my software? I want it to be accessible to all users, but I need write permission to the area to edit my data files. Furthermore, how can I determine in a programmatic way, where the software was installed (not simply where its being called from)? In windows, I use the registry to locate my configuration file which has all of the relevant information, but there is no registry in Linux. Thanks!

Answer 1

The Filesystem Hierarchy Standard (misnamed — it is not a standard) will be very helpful to you; it clearly describes administrator preferences for where data should live.

Since you’re first packaging your software, I’d like to recommend doing very little. Debian, Ubuntu, Red Hat, SuSE, Mandriva, Arch, Annvix, Openwall, PLD, etc., all have their own little idiosyncrasies about how software should be best packaged.

Building

Your best bet is to provide a source tarball that builds and hope users or packagers for those distributions pick it up and package it for you. Users will probably be fine with downloading a tarball, unpacking, compiling, and installing.

For building your software, make(1) is the usual standard. Other tools exists, but this one is available everywhere, and pretty reasonable. (Even if the syntax is cranky.) Users will expect to be able to run: make ; make install or ./configure ; make ; make install to build and install your software into /usr/local by default. (./configure is part of the autotools toolchain; especially nice for providing ./configure --prefix=/opt/foo to allow users to change where the software gets installed with one command line parameter. I’d try to avoid the autotools as far as you can, but at some point, it is easier to write portable software with them than without them.)

Packaging

If you really do want to provide one-stop-packaging, then the Debian Policy Manual will provide the canonical rules for how to package your software. The Debian New Maintainers Guide will provide a kinder, gentler, walkthrough of the tools unique to building packages for Debian and Debian-derived systems.

Ubuntu’s Packaging Guide may have details specific to Ubuntu. (I haven’t read it yet.)

Configuration

When it comes to your application’s configuration file, typically a file is stored in /etc/<foo> where <foo> represents the program / package. See /etc/resolv.conf for details on name resolution, /etc/fstab for a list of devices that contain filesystems and where to mount them, /etc/sudoers for the sudo(8) configuration, /etc/apt/ for the apt(8) package management system, etc.

Sometimes applications also provide per-user configuration; those config files are often stored in ~/.foorc or ~/.foo/, in case an entire directory is more useful than a file. (See ~/.vim/, ~/.mozilla/, ~/.profile, etc.)

If you also wanted to provide a -c <filename> command line option to tell your program to use a non-standard configuration file, that sometimes comes in real handy. (Especially if your users can run foo -c /dev/null to start up with completely default configuration.)

Data files

Users will store their data in their home directory. You don’t need to do anything about this; just be sure to start your directory navigation boxes with getenv("HOME") or load your configuration files via sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application"); or something similar. (They won’t have permissions to write anywhere but their home directory and /tmp/ at most sites.)

Sometimes all the data can be stored in a hidden file or directory; ssh(1) for example, keeps all its data in ~/.ssh/. Typically, users want the default kry name from ssh-keygen(1) so ssh-agent(1) can find the key with the minimum of fuss. (It uses ~/.ssh/id_rsa by default.) The shotwell(1) photo manager provides a managed experience, similar to iPhoto.app from Apple. It lets users choose a starting directory, but otherwise organizes files and directories within as it sees fit.

If your application is a general purpose program, you’ll probably let your users select their own filenames. If they want to store data directly to a memory stick mounted in /dev or /media or a remote filesystem mounted into /automount/blah, their home directories, a /srv/ directory for content served on the machine, or /tmp/, let them. It’s up to users to pick reasonable filenames and directories for their data. It is up to users to have proper permissions already. (Don’t try to provide mechanisms for users to write in locations they don’t have privileges.)

Application file installation and ownership

There are two common ways to install an application on a Linux system:

1. The administrator installs it once, for everyone. This is usual. The programs are owned by root or bin or adm or some similar account. The programs run as whichever user executes them, so they get the user’s privileges for creating and reading files. If they are packaged with distribution packaging files, executables will typically live in /usr/bin/, libraries in /usr/lib/, and non-object-files (images, schemas, etc.) will live in /usr/share/. (/bin/ and /lib/ are for applications needed at early boot or for rescue environments. /usr might be common to all machines in a network, mounted read-only late in the boot up process.) (See the FHS for full details.)

   If the programs are unpackaged, then /usr/local/ will be the starting point: /usr/local/bin/, /usr/local/lib/, /usr/local/share/, etc. Some administrators prefer /opt/.

2. Users install applications into their home directory. This is less common, but many users will have a ~/bin/ directory where they store shell scripts or programs they write, or link in programs from a ~/Local/<foo>/ directory. (There is nothing magic about that name. It was just the first thing I thought of years ago. Others choose other names.) This is where ./configure --prefix=~/Local/blah pays for itself.)