Bug#595652: db packages failing to install...
On Sun, Sep 05, 2010 at 06:58:34PM -0700, Russ Allbery wrote: Holger Levsen hol...@layer-acht.org writes: please clarify what the right behaviour should be and how failing to install without a local db should be treated. Thanks. I agree with jcristau; I think it's reasonable to have database servers be in Recommends, to have postinst prompt for what database to use, and if one choses a remote database that doesn't exist or if one has no database to choose, to have the package configuration fail. My experience is that a package failing to configure let the system in a state that is ill-suited for fixing the issue that caused the package to fail to configure. In particular, apt will not function correctly. So this should be avoided. It has never been required for packages to fail to configure when the user misconfigured them, and it has always been allowed to reconfigure a package in a completly different way after being installed. So I argue that the package must not fail to configure but require the user to fix the configuration and perform an extra step to reconfigure the package. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100929145802.ga10...@yellowpig
Bug#595652: db packages failing to install...
Hi, On Sonntag, 19. September 2010, Russ Allbery wrote: I do think it's okay to require that one answer a debconf prompt saying no, I really don't want any configuration in order to get that opt-out behavior, though, so I'm not sure that quite addresses Holger's problem. if it would be a general debconf question/value pair, that would be totally fine. Something like: dpkgdpkg/allow_no_configuration boolean true Or at least the same name, like mydbpackage mydbpackage/allow_no_configuration boolean true Both variants would allow rather straighforward preseeding of the desired behaviour. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bug#595652: db packages failing to install...
On 19/09/2010 04:39, Russ Allbery wrote: Andrew McMillan and...@morphoss.com writes: In general I think providing an opt out option which does nothing and successfully configures the package is not harmful. While automation i nice, our own imagination can be limited in understanding the full range of possibilities and we should be careful not to over-guess what the user is trying to achieve by choosing such an option. This is a very good point. This came up in a different context with OpenLDAP recently, and I ended up arguing that same point there. There are situations where one really wants to just put the files on disk and tell apt everything is okay and deal with the setup later. I do think it's okay to require that one answer a debconf prompt saying no, I really don't want any configuration in order to get that opt-out behavior, though, so I'm not sure that quite addresses Holger's problem. It's definitely worth talking about if the draft database policy says something else, as it appears to. My rationale is that the package setup may simply require a database; some packages don't have a meaningful stand-alone installation with no database support. I think it makes more sense to fail the configure step than it does to require that the user run dpkg --reconfigure later to re-run the package setup. Heh. Shouldn't that be dpkg-reconfigure :-) Whoops, yes. If I recall correctly one on my recent problem, dpkg-reconfigure cannot be invoked for a package that failed to configure. So, if a question about leaving file in place without doing any configuration is asked, the package should provide a way to (re)answer to this question when it detects the configuration failed (ie dpkg-reconfigure would not fit here). Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c95eaae.7050...@ens-lyon.org
Bug#595652: db packages failing to install...
Andrew McMillan and...@morphoss.com writes: In general I think providing an opt out option which does nothing and successfully configures the package is not harmful. While automation i nice, our own imagination can be limited in understanding the full range of possibilities and we should be careful not to over-guess what the user is trying to achieve by choosing such an option. This is a very good point. This came up in a different context with OpenLDAP recently, and I ended up arguing that same point there. There are situations where one really wants to just put the files on disk and tell apt everything is okay and deal with the setup later. I do think it's okay to require that one answer a debconf prompt saying no, I really don't want any configuration in order to get that opt-out behavior, though, so I'm not sure that quite addresses Holger's problem. It's definitely worth talking about if the draft database policy says something else, as it appears to. My rationale is that the package setup may simply require a database; some packages don't have a meaningful stand-alone installation with no database support. I think it makes more sense to fail the configure step than it does to require that the user run dpkg --reconfigure later to re-run the package setup. Heh. Shouldn't that be dpkg-reconfigure :-) Whoops, yes. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v8q3194@windlord.stanford.edu
Bug#595652: db packages failing to install...
On Sun, 2010-09-05 at 18:58 -0700, Russ Allbery wrote: Holger Levsen hol...@layer-acht.org writes: please clarify what the right behaviour should be and how failing to install without a local db should be treated. Thanks. I agree with jcristau; I think it's reasonable to have database servers be in Recommends, to have postinst prompt for what database to use, and if one choses a remote database that doesn't exist or if one has no database to choose, to have the package configuration fail. I don't think that we should *require* that behaviour, though possibly we can encourage it. Multiple server setups tend to be complex and idiosyncratic, and there may be good reasons why someone is configuring the software without access to a working database, such as when preparing a hot spare, for example, which might interact with the production database in interesting ways if it were to connect. In general I think providing an opt out option which does nothing and successfully configures the package is not harmful. While automation i nice, our own imagination can be limited in understanding the full range of possibilities and we should be careful not to over-guess what the user is trying to achieve by choosing such an option. I could probably come up with a long list of reasons why immediate database connectivity might not be available while I'm installing a package. A few that spring to mind are: * I'm on a ship(/island/branch office/mountain/...) and I'm installing this half of the package now, because I'm here and have the opportunity. I'll do the database bit when I get back to the office next week. * It's 4:35am and the earthquake just wiped out one of our server rooms. I'm trying to get this software running on some equipment in another city and fortunately I *do* have a backup of the configuration files which I plan to apply after installation. * This software is generally configured to run against PostgreSQL, but our organisation insists on running it against $EXPENSIVEDB, which it also supports, but which requires some special magic in the config. And so on. It's definitely worth talking about if the draft database policy says something else, as it appears to. My rationale is that the package setup may simply require a database; some packages don't have a meaningful stand-alone installation with no database support. I think it makes more sense to fail the configure step than it does to require that the user run dpkg --reconfigure later to re-run the package setup. Heh. Shouldn't that be dpkg-reconfigure :-) I know I'd be happier to know that the software was on there, and that if necessary I could run dpkg-reconfigure to use the 'standard' configuration method, but also to know that I had a way of opting out of that, and providing some kind of manual configuration. For those situations requiring more imaginative solutions. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN I have not seen high-discipline processes succeed in commercial settings. - Alistair Cockburn -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283773158.17765.69.ca...@dave.home.mcmillan.net.nz
