Breakdown of libtracker-common
------------------------------
-> tracker-config-file.h
  Used for all GSettings/configs, so libtracker-data, libtracker-fts,
  tracker-store, and the miners.
-> tracker-file-utils.h
  Used to handle operations like getting file size, mtime, etc and
  also for locking files, calculating disk space remaining, etc. One
  important reason for APIs like tracker_file_open() is to make sure
  extractors open with O_NOATIME and to allow posix_fadvise() use
  consistently.
-> tracker-ioprio.h
  Set the I/O priority to be lower than normal to avoid disk
  clobbering. Used by tracker-extract and the miners.
  Could actually be in libtracker-miner.
-> tracker-keyfile-object.h
  Internal and used exclusively by tracker-config-file.h. So wherever
  that ends up, so should this module.
-> tracker-locale-gconfdbus.h
-> tracker-locale.h
-> tracker-meego.h
  Used to notify and keep track of local changes which is needed to
  re-create database collations because sorting can vary by locale
  (among other things).
  The -gconfdbus file is an implementation, which we might even be
  able to remove by now? *Is anyone using still using GConf?*
  The -meego file is use to translate and get the locale on Meego.
  *Is anyone still using Meego?* Would like to remove this.
-> tracker-os-dependant.h
  The tracker_spawn*() API here is only used by libtracker-data and 2
  extractors, mplayer and ps (where we use gunzip, which is quite a
  bad way to do this).
  The tracker_memory_setrlimits() is only used by tracker-extract and
  could be moved there directly or put in libtracker-extract.
Possible solutions
------------------
1. We just make libtracker-common public, perhaps give it a better name (like libtracker-core?) and be done with it. We can then use it anywhere. Advantages: it's quick and easy, Disadvantages: API has to be stable.
2. We split libtracker-common up and move code to more specific areas, e.g. fundamental type functions (A) go into libtracker-data, etc. Advantages: code is more logically placed, Disadvantages: Linking to larger libraries for small API calls might not be so attractive.
3. We create newer smaller libraries with logical parts A to D and. Advantages: Smaller concise areas to group API, Disadvantages: Slightly larger maintenance and distribution burden in the beginning.
4. We copy the code to modules they're needed in. Advantages: Less libraries to link with, Disadvantages: potentially a larger footprint with the same API copied around.