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