Speaking for Docker: it's true that we've only released packages for Ubuntu, but we've been working on a Debian package as well. Starting in 0.6 we expect to offer both in parity.
On a practical note, we are forced to maintain these 2 packages separately if only because Ubuntu uses upstart and Debian doesn't.
Re: network effects of Ubuntu dependencies. In our case that was not a factor, since Docker is a static binary built in Go, and all distros are equally hapless in their management of that. In fact, we are divorcing ourselves completely from distro-specific dependency management. As of this week, docker packages are built by us in an environment we control, not the distro build farms (hint: we build docker with docker). Then we wrap it with fpm and call it a day. Separately, we are working with downstream maintainers of each distro to help them package docker in a policy-compliant way. But those are 2 completely separate tracks.
Hey shykes, I'll come into IRC to discuss this more at some point, but wouldn't it be better to give the main docker package a dependency on docker-startup-scripts and then have that dependency fulfilled either by docker-upstart or docker-sysvinit?
On a practical note, we are forced to maintain these 2 packages separately if only because Ubuntu uses upstart and Debian doesn't.
Re: network effects of Ubuntu dependencies. In our case that was not a factor, since Docker is a static binary built in Go, and all distros are equally hapless in their management of that. In fact, we are divorcing ourselves completely from distro-specific dependency management. As of this week, docker packages are built by us in an environment we control, not the distro build farms (hint: we build docker with docker). Then we wrap it with fpm and call it a day. Separately, we are working with downstream maintainers of each distro to help them package docker in a policy-compliant way. But those are 2 completely separate tracks.