[Openstack-devel] Bug#677400: Bug#677400: This is not a bug, it is a feature!

[ghe. rivero]

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" <thomas at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20120618/96e2496e/attachment.html>