[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#595652: db packages failing to install...

package: debian-policy
x-debbugs-cc: debian-release@lists.debian.org


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 
<jcristau> i'm arguing that requiring either a local db or configuration is 
<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 
<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 
<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


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: