package: debian-policy x-debbugs-cc: debian-rele...@lists.debian.org Hi,
please clarify what the right behaviour should be and how failing to install
without a local db should be treated. Thanks.
context: bugs such as #595594
<jcristau> h01ger: fwiw i still think that if an app needs to talk to a db
server and you refuse to configure it on install, or it can't talk to the
server, the package is within its rights to exit 1 from postinst.
<h01ger> jcristau, so you're not argueing this is a bug in piuparts to detect
this as a bug? i dont think so, its in (almost?) all cases possible to use an
external db server, so the package should install cleanly without a local
db....
<jcristau> i'm arguing that requiring either a local db or configuration is
sane
<h01ger> i agree
<jcristau> yet you file serious bugs against packages that do that..
<h01ger> yes. assume i have configuration, then the install still fails...
thats why i file bugs
<jcristau> eh?
<jcristau> DEBIAN_FRONTEND=noninteractive is not configuration
<h01ger> sure. after that i can copy/edit the configfile and start the service
<jcristau> after that you can copy/edit the config file and
dpkg --configure -a
<h01ger> thats not how its usually done with fai/puppet/etc
<jcristau> that doesn't make it an rc bug
<h01ger> fine. (i'm totally for the release team defining the severities...)
but then please document this change. it used to be that fails to install is
rc.
<jcristau> i don't know about the release team. i'm stating my opinion.
<luk> jcristau: are you arguing that these have no sane local default so they
are in their right to fail to install?
<jcristau> luk: there's a sane default, which is to use a local server. if
there's no local server, and the admin doesn't configure a different one,
yes, i'd say it's ok to fail configuration
<luk> so I guess the situation is: packages don't depend on a database server
as the database can be remote and they fail to install as there is no
database configured nor is there a local database?
<luk> I don't think they should fail to install unless they are absolutely
useless without such a database
<phil> luk: Well, the other option would probably mean that there's a script
for the admin to execute to create the database content. Which you'd usually
take care of in the postinst, no?
<luk> well, I think there is a difference between making sure the package can
be used with remote databases and making the package crippled unless you
install a database locally or remotely
<jcristau> crippled?
<luk> I'd rather see the package depend on a database server and have a sane
default than packages failing to install because of flexibility
<luk> jcristau: yes, you need manual action and another dpkg run to have it
installed if you 'forgot' to install a database first
<jcristau> well that's what recommends is for
* KiBi nods
<phil> But all people think they're more clever than recommends.
<KiBi> well that's what cluebats are for
<luk> nope, recommends is for packages that are not absolutely needed, the
package should still install and be somewhat functional if you try to install
it without its recommends
<jcristau> eh?
<phil> That's what suggests are for.
<phil> :)
<jcristau> the package is functional if you install without a db server. you
just have to configure it.
<luk> wtf, what are depends for in that case?
<luk> it's not functional if it does not even install...
<jcristau> it installs. it doesn't configure.
<luk> not configuring in dpkg speak is not being installed...
<jcristau> *shrug*
<luk> as you still need to solve that before you can install anything else
<Corsac> “configure” it as the dpkg state?
<jcristau> Corsac: configure as in 'foo.postinst configure', yes
<jcristau> luk: you need to solve that before you can install reverse
dependencies. which i think is fair enough
<luk> only if you argue that the package absolutely cannot work without a
database and that it's perfectly fine to not depend on a database if one
needs one
<jcristau> yes
<luk> I think it's perfectly fine to make it easy to use a remote database
though I don't think it's a good idea to not depend on a local database if
one needs a database and thus fail to have a working default configuration
<jcristau> the default configuration is neither 'ignore recommends'
nor 'noninteractive frontend'
<jcristau> anyway, we're not going to agree, so i'll drop this
<luk> default configuration should work with noninteractive frontend IMHO
<Corsac> well, non-interactive with recommends and interactive without should
work, but both at the same time might not
<phil> Corsac put it well, I think. But possibly that's not codifyable.
* h01ger thinks you must reach consensus, else i'll have to assume the status
quo hasn't changed and thus will continue filings serious bugs :-p
<jcristau> i think debian-policy would be a better place than here
<jcristau> (my fault, i know)
* KiBi nods, for both ;)
<h01ger> why? its a release criteria.. its a bug, just how much is the
question...
<jcristau> because it's a policy question
<jcristau> and we don't even agree on whether it's a bug
* h01ger filling a bug quoting this irc log now
thanks,
Holger
signature.asc
Description: This is a digitally signed message part.
