A package manager whose packages are all install scripts that depend on packages from explicitly-specified repositories for a lower-level package manager. Somehow I feel like this must have been tried already before -- maybe in the RPM side of the tracks, or zero-install, or klik?
This does more than just package installation, it operates at a higher level. A service may require several packages that need to be installed, configured, then configured to work with each other. All of that is captured in a charm giving you a way to easily deploy a service. So capture your start to finish setup for any service you use in a charm and you can no deploy, and scale that service, using Juju.
All of which is possible by creating a package for existing package managers. It's how I tend to manage services: I build packages that depend on the other packages I need, and that uses post-install hooks to orchestrate the connections between various services, or replaces config files.
The level of support for cleanly handling things like replacing config files vary between package managers, but I've done this easily enough with both dpkg and rpm.
Sure, you can use dpkg to orchestrate connections between services on the same machine, but last I checked dpkg isn't aware of other machines running other services and orchestrating the connections between those. Service orchestration between machines is something Juju excels at. It's really server and service orchestration abstracted so that you don't have to worry about what machine is where and connected to who. Juju maintains those relations for you, so it's really more like apt for the cloud.
I have no idea whether their offering is any good or not, but I don't find your argument persuasive. The fact that someone else tried to do something similar does not mean that this can't work well, or that it shouldn't be done.
People once said that Apple shouldn't do a tablet because it had been done before and there wasn't a market for them.
