Symbolic link command should use -f flag consistently

[artemp]

https://travis-ci.org/mapnik/mapnik/jobs/152731996#L486

ln: failed to create symbolic link `/home/travis/build/mapnik/mapnik/mason_packages/.link/mason.ini': File exists

I'm getting bunch of errors like above which are temperamental. I think the solution is to always unlink before creating a symbolic link via -f flag.

/cc @springmeyer @kkaefer

[springmeyer]

The odd thing about this bug is that mason_packages/.link/mason.ini is not a file that should ever get created as far as I can tell. It may be that mason_config is getting called while the current working directory is not correct (or there is a race condition). The mason_config functionality was added in bfc612d but the bug is likely from #216 (which fixed other linking problems).

[kkaefer]

@springmeyer the mason.ini files are created as part of #176

[springmeyer]

I see the problem now. The mason.ini for each package is being linked to the same place, so each packages tries to create .mason_packages/.link/mason.ini. This is because of the usage of lndir which creates "a shadow directory of symbolic links to another directory tree". The lndir command is used since it is way faster than ln -s per file. But with lndir we don't have control over ignoring files that would clobber each other across packages. Hmmmm.

[springmeyer]

@kkaefer what do you think about storing mason.ini at ${MASON_PREFIX}/<package-name>.ini instead of ${MASON_PREFIX}/mason.ini. That would be a breaking change of course, but it would allow the ini config to be used within a linked/collapsed directory structure.

[kkaefer]

While we could rename it, we decided to deprecate linking

[lightmare]

This can be closed as per the above-mentioned PR.

[springmeyer]

Thanks @lightmare!