hi! sean finney wrote:
recommends can be ignored, but that's the point of recommends vs depends.
Recommends has historically been really "weak", and that is changing, but that's not the real reason for the remote packages.
Recommends isn't good enough because the decision whether to install the DB needs to be made early in the game, to resolve all the other packaging issues at the same time (dependencies, conflicts, etc). That's why we are looking at a package -- it is something that has all the metadata required at package-dependency-resolution time.
Personally, "Recommends" have been a pain to me in the past by getting pulled in by package installations where I do not want them. When I am installing a web application I am often separating the application and database for security reasons as much as for performance ones, and I don't usually want to accidentally have database servers on the internet - even unused ones.in such a case i would say that you should pay closer attention to what you're installing. for example, if i'm installing a new potentially big package on a system, i'll do a dry-run before the real thing and/or read through the list of stuff to be installed.
Being careful is not enough. If the package pulls in the database, and expects to perform database setup locally, when you have a remote DB, then you are in trouble. Either forgo the package, or spend a lot of time reworking the package to work with a remote DB. And you end up with a package that's only good for you -- forked from the Debian package.
that said, it would be fairly easy (and not dependant on mucking with the package management system) to determine if a local database server is not installed, and inform the admin giving them the "stop now, i'll install a db server" vs. "i'm installing on a remote server" choices in debconf. something like this would be pretty easy to throw into dbconfig-common.Excellent :-)
Hmmm. In the middle of postinst, starting a new "apt-get install foodb" is going to run against the locks, present all sorts of conflict resolution problems, configuration, error/failure handling, the works. Just say no to nested apt-get install invocations ;)
I do agree on the other hand that perhaps _having_ those packages in the archive is too much, and they could be built on the fly (and installed) by dbconfig-common scripts. It's still unclear to me how to explain that that will happen to APT when it's resolving dependencies. One way would be saying that dbconfig-common "provides" foodb-server but that'd mess up the case of actual local dbs.
There _are_ problems we're trying to solve -- I wish recommends waas enough -- let's figure them out.
cheers, martin