Design of system packages

A ticket to discuss how to design "system" packages for mason, which are a very unique kind of package. This is a place for @kkaefer and @springmeyer to sync up on goals and others to read to get some background on why system packages are tricky.

My understanding is that a system package:

• makes it possible to declare an explicit dependency on something like zlib without installing a custom version. (**This can be very important because something like zlib is often a dependency of so many apps that mixing a custom version of zlib would be a path to ABI conflicts and much pain).
• still allows mason to report cflags and ldflags for where the system's zlib is located such that a build system can depend on mason to supply platform-specific flags.
• does not get published since there is nothing binary to publish. Therefore the script.sh does all the work dynamically on each system.

But one challenge remains: is it safe to put the -L/path and -I/path of the system package on the compile and link paths? This can result in conflicts with other system libraries that you might be intending to statically link.

I ran into a situation like this with libpq (postgres client library) on OS X, which is the motivation for trying to have mason cflags and mason ldflags return symlinks to the location of a system package rather than the real location (https://github.com/mapbox/mason/commit/4e14abb4e08a8faeb0df49b388dd1cc44b50e3c3). However, due to the nature of the postgres build system I ultimately found I could not avoid -L/usr/lib ending up on the link flags, even if mason did not put it there. So my changes were not enough. And in addition they were not correct for every platform and therefore caused other unintended breakages downstream in mbgl which I'm sorry about.

@kkaefer has made some progress further cleaning up the zlib-system package (https://github.com/mapbox/mason/commits/zlib-system). Hopefully we'll be in good shape now and we can keep the symlinking addition. Or we can remove it. Let's discuss.

Start by reading the zlib-system branch and the linked commit, then compare how mason cflags and ldflags handle system-library paths across platforms. Done means reaching an agreed design for system packages and deciding whether symlinking should remain; this issue is primarily an unresolved discussion rather than a scoped implementation task.