You say you're wary of vendor lock in, but then you're using Ansible, which is locks your deployment procedure. Packages actually give you more flexibility. If

You say you're wary of vendor lock in, but then you're using Ansible, which is locks your deployment procedure. Packages actually give you more flexibility. If you don't put all the build process into debian/rules, but keep a makefile/rakefile/antfile/scons file/setup.py and run appropriate build tool from debianization, you get something that is quite easy to translate to RPM spec or some other packaging format (been there, done that, got a T-shirt). The benefits from keeping such a package are numerous: - build procedure (its entry point) is stored in a Well Known Place[tm] - there is a Good Place[tm] to specify dependencies (including dependencies from OS and other languages!) - build process is only run once, outside of the deployment phase - rebuilding a package is repeatable (assuming that you prepare source packages, also for the libraries you use) - deployment is more repeatable and much faster than with rebuilding libraries for every installation - DEBs/RPMs are trivial to work with in all the popular (and less popular) tools, like Ansible, SaltStack, CFEngine, Puppet, Chef, or Dockerfile; the reverse is not true - DEBs/RPMs are easy to upgrade, downgrade, and to deploy an old version of your software in the first place - DEBs and RPMs give an easy way to verify correctness of their files - preparing an environment for development for a new team member is much, much easier (`apt-get build-dep mysoftware' and you're pretty much done) I'm yet to encounter a drawback of this approach, apart maybe from lack of sexiness because of its age (it was invented two decades ago).