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-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
