Re: [Vala] Getting path to my program's directory

[Jan Hudec <bulb ucw cz>]

On Fri, Aug 28, 2009 at 20:25:39 +0300, Arkadi Viner wrote:
> I am writing my software for Linux and using Ubuntu for 2 years already. but
> as it is my first program in Linux, I don't really sure how to split all the
> installation files to their proper locations.
> Maybe it is just me but all this idea of how program files placed to paths
> by their usage is really confusing to me. It make it very hard to find all
> files you need to delete if you uninstalling  the program and if it wasn't
> installed from packages... Maybe I will after I finish writing my program
> make it "Linux style installed" but I will need help in doing that... some
> guide... tutorial...
>
> Maybe some one would explain to me why "Linux style installation" is chosen
> for Linux based operating system ? I just see more disadvantages in it...

Most programs on Linux are installed from packages. In fact, most of them are
installed from packages on Windows and other systems as well these days,
because it's rarely enough to extract a directory (entries in application
menu need to be created, file associations registered etc.).

On Linux (and other Unix) systems there are two solutions to keep manually
installed programs in separate directories:
 - In the /opt directory, each application suite gets seaprate subdirectory
   where it is installed and is used like that.
 - GNU stow (http://www.gnu.org/software/stow/) is a tool that allows one to
   install application in a separate directory and symlink it to the place
   where files will be found at runtime.
Additionally there is the checkinstall
(http://asic-linux.com.mx/~izto/checkinstall/) tool, that records what files
are created during installation of some program and writes appropriate
metadata for the package manager to be able to uninstall the program later.

There are several reasons to install files by their purpose. Some of them are
not applicable to common desktop, but unix grew as a server operating system
and is used on servers a lot, so the use-cases are important:

 - Placing all binaries in a few directories and all libraries in a few other
   directories makes searching for them by shell and dynamic loader
   respectively more efficient, because they only need to read a few
   directories and those directories don't contain many other files.
 - Placing all configuration files in one directory makes it easier to back
   up more often. Configuration files are small and more important, so
   different backup strategy is useful.
 - Placing data in different place than applications is again for backup
   reason. Also the application files can be on read-only media most of the
   time, which might have various reasons (live systems running from CD,
   shared SAN, shared file for virtual hosts, security reasons etc.).
 - Placing platform specific data (lib) separately from platform independent
   data (share) similarly allows sharing one copy of the independent data
   across computer lab, while the architecture specific data need to exist in
   several variants.
 - Placing basic system files (/) separate from applications (/usr) allows
   e.g. mounting the application from network storage.

It might look like most of the use-cases are not important now that disks are
so large, but:

 - If you try to run several virtual machines on comodity hardware, space
   gets precious resource again. Plus since the host manages caches, it's
   more efficient to read one copy of some file in all guests than to read
   different copies of it.
 - Disks are large, but extremely slow compared to CPUs and memory and SSDs
   are not so large. So it makes sense to put files on different media split
   by purpose.

For the exact suggested layout you can refer to
http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>