On Tue, Aug 02, 2005 at 08:11:48AM +1200, Martin Langhoff (nzl) wrote: > Recommends has historically been really "weak", and that is changing, > but that's not the real reason for the remote packages. yes, i believe that the newer package management frontends provide a way to automatically bring in the recommends now, though i haven't verified this. > 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. but what about cases where an app has been configured for a remote database, and there's a package installed, and then the admin wants to do one locally. you're still in the same position as you'd be w/recommends. > >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. the presence of a db shouldn't necessarily imply that an admin wants to install locally on that db. with dbconfig-common they will still have the option of how to install. > >>>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. > > 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 ;) what i meant by "stop now, i'll install a db server" was not to inline more packages into an apt-get call (because we don't even know that they are using apt), but instead to fail the postinst, which would leave the package unconfigured, allowing the admin to install the db server package, which iirc will automatically attempt to reconfigure the "failed" package after installing the db server. sean --
Attachment:
signature.asc
Description: Digital signature