We use two components from boost: asio and optional. They're typically included with:

#include <boost/asio.hpp>
#include <boost/optional.hpp>

My understanding is that those are header-only libraries required at the build stage so you actually don't need any boost-related package at the run stage.

I think that if it weren't for the boost::optional stuff, we would only have to install libasio-dev at the build stage. Would this change the need for a multi-stage build?

I tried using it without the boost dependency in the running stage, but then requests fail with a Internal error vroom error.

I tried to only include libboost-iostreams1.67.0 of the boost suite (earlier versions, e.g. 1.62.0, don't seem to be distributed for debian:buster), but again the same error. Maybe it doesn't include the optional stuff or 1.67.0 is not compatible with vroom?!

I saw the vroom #312 you put in. That would be really cool if boost wouldn't be a dependency at all anymore. Not only for Docker.

Then I won't do any more on this and we can fix once vroom was updated. Ok for you?

That would be really cool if boost wouldn't be a dependency at all anymore

This won't happen totally because there is still the need for boost::asio (but then installing libasio-dev should be enough for the build stage).

I'm puzzled and not sure the problem comes from either boost::asio or boost::optional because:

• asio is header-only (see installed files)
• if think there is no system library required for the boost::optional part (though there don't seem to be a simple way to install only the boost/optional headers without pulling the whole libboost-dev stuff).

We may need a bit of digging here, can you spot the error logged by vroom-express for the Internal error you mention?

asio is not exactly header only, since it requires libboost-system (https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/using.html) or at least vroom is compiled so that it requires it. So installing

        libboost-system1.67.0
        libssl1.1

should be enough, if vroom is compiled without linking against libosrm.

The uses of boost::system in vroom are pretty limited though and could potentially be removed, if removing libboost-system as a runtime requirement is important.

@krypt-n thanks for stepping in!

The uses of boost::system in vroom are pretty limited though and could potentially be removed

Could you expand a bit on how we could achieve this? Would this be as simple as replacing the boost::system::error_code in routing/http_wrapper.cpp by some other custom exception?

if vroom is compiled without linking against libosrm.

I don't think we should worry about this (at least for now) in the context of a simple Docker image.

Ah sorry, I was mistaken. It seems like boost::system is a hard requirement for asio and thus libboost-system needs to be present at runtime. However, this just adds a at most few MB to the docker image, so I think it can be ignored

Oh great, thanks so much for the insight @krypt-n ! I'll amend that next week!

I don't think we should worry about this (at least for now) in the context of a simple Docker image

Ýeah I agree. In the future, maybe we can extend the Dockerfile to optionally build libosrm with a build argument, so an additional routing container wouldn't be needed.

Yep, that worked @krypt-n, thanks again:) Image size now down to 209MB uncompressed, great!