> They want you to be able to apt-get install <thing> and have <thing> working, out of the box, with no further work on your part.
Except that there is practically no way for say, winbind, or openldap, or bind to be able to start up successfully without configuration first. Then the oh so frequent case nowadays of preparing a deployment image in a chroot and bang, install fails because of unwanted starting services that conflict with the host.
> This is the same reason you probably shouldn't, for instance, do development against the packaged ruby
Excuse me, this is insane. You're using a well-maintained distribution because you don't want to manage your own installation of Ruby or Python or Perl or PHP and countless modules, frameworks and the like, on the production systems. All the point of running Debian is developing against the provided binaries, because you want to use the same versions in dev and deployment, don't you??? and have an easy maintenance, upgrades, etc.
What is needed is a simple switch to apt-get/aptitude/dpkg to NOT start the services when installing, and maybe some other switches to NOT run preinst/postinst. That's it.
> Except that there is practically no way for say, winbind, or openldap, or bind to be able to start up successfully without configuration first.
If you know the configuration you want, you can write the configuration files first. `DEBIAN_FRONTEND=noninteractive apt-get install <foo>` won't (or shouldn't) overwrite pre-existing config files.
> Then the oh so frequent case nowadays of preparing a deployment image in a chroot and bang, install fails because of unwanted starting services that conflict with the host.
What I was saying above about the system not being designed for you? This is exactly that. I'm not saying this isn't a valid thing to want to do, just that the system isn't explicitly designed to support this use. It is unsurprising that there are rough edges.
I wouldn't be at all surprised if someone comes up with a container-based approach which makes this just work, but I've not seen it done yet.
> Excuse me, this is insane. You're using a well-maintained distribution because you don't want to manage your own installation of Ruby or Python or Perl or PHP and countless modules, frameworks and the like, on the production systems.
No, I'm using a well-maintained distribution so that I don't have to take control of anything I don't want to care about. I know that the system outside what I'm directly responsible for is stable. No surprises.
I do want to care about my runtime. I've found it makes more sense to treat the runtime as part of the application I'm working on rather than rely on the distro-supplied packages because the distro's goals are simply divergent from my own. They want absolute stability; I might want to upgrade a patch level so I can take advantage of improvements in GC, say.
This is potentially more true of ruby than, say, perl. Going back to my earlier point, I think this is because there have historically been more apps in Debian implemented in perl, so whatever you're doing, your needs are more likely to overlap with what Debian already provides for itself. The same goes for PHP and Python, to an extent.
> All the point of running Debian is developing against the provided binaries, because you want to use the same versions in dev and deployment, don't you???
You don't have to use the Debian-supplied ruby to know that you're running the same version in development and production. Personally, I use the Debian-supplied infrastructure tools to build my own ruby packages, and to provide a repository which both dev and production can pull from.
The bonus from this is that I don't need to do a big-bang upgrade of my app every time Debian roll out a new stable release because they've changed the runtime version and all the associated packages.
> What is needed is a simple switch to apt-get/aptitude/dpkg to NOT start the services when installing, and maybe some other switches to NOT run preinst/postinst. That's it.
...will unpack apache2 and its dependencies without running pre or postinst scripts. Fiddly, but it's doable. Now, for extra fun, you get to check each of the dependencies and find out which pre and postinst scripts you did want to run after all.
I agree that this should be less irritating. policy-rc.d is just way too opaque, and it has the wrong affordance. I don't want to set "don't run daemons" as a system-wide policy; I want it as a setting for a specific call to apt-get. It's another example of a system being used because of what it can do, rather than for what it was designed for. This rarely ends up looking good.
Except that there is practically no way for say, winbind, or openldap, or bind to be able to start up successfully without configuration first. Then the oh so frequent case nowadays of preparing a deployment image in a chroot and bang, install fails because of unwanted starting services that conflict with the host.
> This is the same reason you probably shouldn't, for instance, do development against the packaged ruby
Excuse me, this is insane. You're using a well-maintained distribution because you don't want to manage your own installation of Ruby or Python or Perl or PHP and countless modules, frameworks and the like, on the production systems. All the point of running Debian is developing against the provided binaries, because you want to use the same versions in dev and deployment, don't you??? and have an easy maintenance, upgrades, etc.
What is needed is a simple switch to apt-get/aptitude/dpkg to NOT start the services when installing, and maybe some other switches to NOT run preinst/postinst. That's it.