We should not use _profile_base_location_ in another section, because
slapos.recipe.cmmi only know how to ignore it in the cache key
computation when _profile_base_location_ is used directly in the
slapos.recipe.cmmi section.

cairo is not duplicated. It was my mistake

These links are no longer available.

XXX since we have shacache, this should not be needed. There must be
something wrong with my shacache setup.

previous URL is no longer on CPAN

works on my machine

We use slapos.recipe.cmmi to benefit from cache, but nothing is
compiled, so it's semantically incorrect

Because apr / apr-util are using slapos.recipe.build:download-unpacked
(which does not use shared cache), they cannot be cached.

We workaround this by using slapos.recipe.ccmi without actually
compiling, but just copying the files to the expected location.

This could just be using slapos.recipe.cmmi

We build pkg-config twice, so maybe we should install twice in two
different locations ? ( I'm not sure of the exact reasons for compiling
twice, so I'm still not sure if this is a good idea )

This patch is a mess. I started reorganising, splitting in two parts (
which seemed to make sense as we install twice - install in two
different directories for each compile options ), but then stopped and
left this as unfinished.

mroonga installs plugin .so files in mariadb directory, violating the
isolation of parts principle.

all fonts are installed in parts/fonts/* which is a violation to the
principle of parts isolation.

Options
 * install each font package in parts/font-package-x and configure the
path in the instance ( if possible )
 * install everything in one buildout section (how ?)

file depends on a slapos.recipe.build:download-unpacked part, so it
cannot be shaared.

Options:
 * update dependency, file >= 5.33 supports msooxml
 * rewrite file-msooxml as a patch
 * rewrite file-msooxml as a slapos.recipe.cmmi ( but that's too much
hackish)

randomsleep uses slapos.recipe.build, which does not support shared
feature.

It seems we can rewrite it using slapos.recipe.cmmi or other options ?

The work on cmmi share makes me believe slapos.recipe.build is not
necessary and we can use slapos.recipe.cmmi everywhere, but I don't know
the reason that leaded us to have two duplicates recipes in the first
place.

Test suite is really large ( > 10K files ) and we do not run tests, so
let's save disk space a bit.

See "Conditional configuration sections" of buildout documentation.
http://www.buildout.org/en/latest/topics/variables-extending-and-substitutions.html#conditional-configuration-sections

To make it possible for the part options to refere to ${:location}, we
use @@LOCATION@@

This will make integration with `shared` option of slapos.recipe.cmmi
easier.

because we need to export `:executable`, we guessed the installation
location. Instead, introduce a new section to install.

`python2.7` section just expose the options and will be available only
after build.

We stop using slapos.recipe.build:cpan , but these unstable components are
not ready and not being actively maintained, so move them inline in
mioga software, which was the only user of these components.

When the work on this is resumed, we should switch to perl-CPAN-package
here as well.

Generate a wrapper with all dependencies available

${perl:location} is now a perl without any package, components using
perl with one specific package must switch to using the perl with the
dependent CPAN packages installed.

Installing everything in site_perl is not the "buildout way" and is
incompatible with the upcoming shared slapos.recipe.cmmi

erp5, mariadb: Allow users to set additional environment variables to mysqld to use third party ODBC libraries for CONNECT storage engine.

more discussion at nexedi/slapos!266

!311 was merged a bit too fast. After test suite was repaired ( the test node was stuck updating the git repository ), [test](https://nexedi.erp5.net/test_result_module/20180507-19395E1F/2) was not passing on testnode, because path was too deep.

While debugging this, I realized this check was wrong, because supervisor [also append the pid](https://github.com/Supervisor/supervisor/blob/70720a0311d868fbf58a31cd26a7147921dcff29/supervisor/http.py#L564-L574) to this path, so the path is even longer. I just checked that we have room for 7 digit pids.

Because path was too long on test node, test now run with `SLAPOS_TEST_WORKING_DIR` set to a slightly shorter path that's enough for this case.

There are some other minor fixes, see individual commits.

/cc @Nicolas @luke @rafael 

/reviewed-on nexedi/slapos!325

For supervisord AF_UNIX socket

This is a convention from
http://community.slapos.org/slapos_community/wiki/slapos-Wiki.Home/developer-SlapOS.Conventions.Guidelines

fix all getInstanceParameterDict typos

supervisord creates a socket with pid in the name, so we have to account
for the space of pid.

Because it's not so easy to know the max size of pids, we just assume 7
places.

otherwise we leak zombie slapproxy processes