On 2012-10-30 19:42, Paulo Pinto wrote:
Not really.
Let's say you compile everything fine, but on the deployment
platform, some IT guy has the cool idea of changing some configuration
settings.
That change will have as side effect that some third party dependencies
will now be matched to another version different than what was used by
the package manager.
Again, then you haven't specified the dependencies correctly. If you
just specify that "foo" depends on "bar" then you have only yourself to
blame. You need to specify the exact version, i.e. "bar-1.2.3". If you
cannot specify the exact version of an indirect dependency then you're
not using a very good tools.
RubyGems together with Bundler is a great package manager. You specify
the direct dependencies of your software and the tool will write down
all dependencies, direct and indirect, in a "locked" file, including all
versions.
When you deploy your software it will install and use the packages from
the "locked" file. Your code cannot access any other dependencies that
is not listed in the file.
You'll spend a few hours trying to track down the issue, in case you
forget about checking the dynamic resolution order.
This is why Plan 9, Singularity and the Go guys are so much against
dynamic linking.
One can always do stupid things, it can be quite hard to protect
yourself from that. I mean, the IT guy can just replace your newly
deployed application with a different version and no static linking in
the world can help you there.
--
/Jacob Carlborg
