This was not shared, installing mroonga writes a plugin in mariadb's
plugin dir and it's not allowed for one part to write in another part's
folder.
The approach is to install mroonga plugin in it's own plugin directory,
then copy all mariadb default plugins in this plugin directory and
configure instance to use mroonga's plugin directory.

Users will need to generate a proper fonts.conf and set it as
$FONTCONFIG_FILE environment variable.

The recommended approach is now to generate a font.conf file using
slapos.recipe.template:jinja2 since font.conf now needs entries for all
directories containing fonts.

Instead of the previous approach which relied on a side effect of
installing *-fonts parts that would write in parts/fonts/ and make the
fonts automatically available to applications, use a new approach where
each part is "pure", without side effects.
To make the fonts available to applications, a fontconfig font.conf
listing all the parts with fonts needs to be generated and set as
$FONTCONFIG environment variable.

A template font.conf is included in component/fontconfig

This keeps the bug compatibility that we ignore error in the build.

jsl does not understand modern javascript syntax and does not do so many
useful checks, it would be waste of time trying to fix it.

We now need to refer to the part where the dictionnary was installed.

this allow to share aspell component. Users needs to install the part
with dictionnaries, ie. aspell-en-dictionary instead of simply aspell

apr and apr-util are now build separately. I'm not sure there was any
benefit with that approach of copying the directories inside apache
source tree before build.

Using extra modules, like apache-antiloris require to install apache in
non-shared mode.

This also removes apache-antiloris from cloudooo and erp5 stacks so that
they can use apache as shared. Even if the section was installed, this
was not used anywhere.

Otherwise it will try to use development system package and we will have
different results depending on wether that package is installed or not.

Note that because of a typo in the environment variable (this makefile
uses $LDFLAGS, slapos zlib was not effective so far)

In my environment this relinking to system package, I don't know why it
works in other cases.

See merge request !723

See merge request !724

Since `buildout 2.7.1+slapos002`, we `Check that sections don't installed the same path`, so we need to adjust some profiles which were not respecting this rule.

This fixes the regression introduced by nexedi/slapos@bbd70f7d

See merge request !726

use another port so that we can run tests on test node, port 8080 is
already used by testnode.

Install a promise so that we know when instance is ready
Use a builout.hash.cfg for easier management

By using a short filenames like "httpd.crt" or "httpd.key", we risk have
conflict with users of this stack. Use a name with more context, that
should likely not be used by applications.

This solves an issue with lamp stack, that was visible with nextcloud
software:

     While:
       Installing ca-apache-php.
     Error: The following paths are already installed by other sections: {'/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/inst/ncs2/srv/ssl/certs/httpd.key': 'ca-monitor-httpd', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/inst/ncs2/srv/ssl/certs/httpd.crt': 'ca-monitor-httpd'}

We were using caddy-log-access-header to make sure we have at least one
file to include, but this was implemented in a way that the config file
was overwritten.
Reimplement this by using caddy-log-access-empty to create an empty file
when there are no slaves, caddy-log-access otherwise.

If we list eggs as eggs= of a zc.recipe.egg section, the scripts of these eggs
will be installed again.

This fixes this error while building:

    While:
      Installing extra-eggs.
    Error: The following paths are already installed by other sections: {'/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucased-manage': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-key-id': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-updater': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-rerequest': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucase-probe': 'caucase-eggs', '/srv/slapgrid/slappart8/srv/testnode/cvt/inst/test0-0/tmp/soft/72b4c4e0472506664a0cb3cc44bbb0b2/bin/caucased': 'caucase-eggs'}

The same caddy-log-access section was defined more than once, keep only
one implementation.
Remove some trailing spaces.

library dir is lib64 in that case

npm invokes node from $PATH, so make sure we have proper node version in
PATH.

-e is already set by default in slapos.recipe.cmmi 0.13

let's use the one from stack/slapos.cfg because there's a version
confict