package: debian-policy x-debbugs-cc: debian-release@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
Attachment:
signature.asc
Description: This is a digitally signed message part.