<p>This will need a little bit of thinking but with this fix we solve the piupart issue that this bug is about.</p>
<p>Ghe Rivero<br>
</p>
<div class="gmail_quote">El 18/06/2012 19:51, "Thomas Goirand" <<a href="mailto:thomas@goirand.fr">thomas@goirand.fr</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06/19/2012 12:43 AM, ghe. rivero wrote:<br>
> Hi everyone,<br>
>    i finally managed to find the problem (not uploaded a fix, but it's<br>
> pretty trivial).  As Zigo noted, scripts shouldn't change conffiles,<br>
> but in our case, as we are using dbconfig, if we use other options<br>
> than the defaults ones, it's ok to do it. In our case, using the<br>
> default options (or non-interactive as piuparts does) the problem is<br>
> that in nova-common.postinst script (line ~81)<br>
>      SQL_CONNECTION="sqlite:////$dbc_basepath/$dbc_dbname"<br>
>  we add an extra / (slash) after sqlite,  making the conf file<br>
> different than the package default provided. The solution is as eassy<br>
> as remove one the /. I'll wait for comments to provide a fix for it.<br>
><br>
> Ghe Rivero<br>
<br>
Hi Ghe!<br>
<br>
The issue isn't only with the default. That's not the way to fix. The<br>
file shouldn't be marked as conffile, and that's it.<br>
<br>
We should allow everyone to upgrade from one version to another, without<br>
prompting anything to the user if the user didn't edit anything in the<br>
config file. That's basically what the policy tells.<br>
<br>
If let's say, the user decides to use MySQL when configuring the package<br>
using debconf, then later on upgrade his nova-common package, then we<br>
really don't want dpkg to prompt the user about new stuff in the config<br>
file. Especially considering that the user may decide to overwrite the<br>
file, which may potentially break his configuration.<br>
<br>
Also, the policy tells that we *must* read the configuration from the<br>
configuration file in the debian/nova-common.config. That is: if the<br>
user edits /etc/nova/nova.conf and decides, for some reason, let's say<br>
to switch from sqlite to mysql, we should be able to detect that, and<br>
have dbconfig-common catch up with it. Currently, it's quite hard to do,<br>
because dbconfig-common cannot be preseed easily. So again, currently,<br>
that has to be done, because our package isn't policy compliant.<br>
<br>
I'm really not sure how to fix this issue. I don't think parsing<br>
/etc/nova/nova.conf to find out what values are in would be hard, but<br>
I'm really not sure how to preseed stuff in dbconfig-common. Ghe, could<br>
you explain to me how to do dbconfig-common preseed, and what's the<br>
format of the files in /etc/dbconfig-common/? It's currently a bit<br>
cryptic to me.<br>
<br>
So, anywa, what we should do (and what I did) is: we don't ship a<br>
/etc/nova/nova.conf in the nova-common package, and create it when the<br>
postinst script is ran. For this, I've put it in<br>
/usr/share/doc/nova-common/nova.conf.dist. This in our Git repository<br>
right now.<br>
<br>
Please note that the release team agrees with me, and that I had such<br>
issues in the past, so I believe I'm right.<br>
<br>
Thomas<br>
<br>
<br>
<br>
</blockquote></div>