[Openstack-devel] Bug#677400: Bug#677400: Bug#677400: This is not a bug, it is a feature!
opal at debian.org
Mon Jun 25 20:46:12 UTC 2012
I still do not fully agree with you. But as I understand you have solved
the issue with another git commit so I will not argue to death. :-)
See further below.
On Tue, Jun 19, 2012 at 01:48:45AM +0800, Thomas Goirand wrote:
> 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.
All admin changes in files in /etc/somewhere must be prerved. This is
what the policy says. So either we store this information in some other
place and read that from the file in /etc/nova/nova.conf. That means
that nova must have that kind of support so that other files can be
included from nova.conf.
Another way is to keep it being a conffile, but then read the data
> 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 someone actually enter something different from the default in
debconf question then it should really ask if it tries to install a new
version. If not the change will be overwritten. That is solved by the
solution from Ghe.
> 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.
For this I fully agree!
> 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.
Fully agree to this part.
> 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.
It is a bit cryptic to me too. :-)
> 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.
Is this really a good solution? What happens when we upgrade the
configuration file in the package? Normally a question is asked by
dpkg whether it should be replaced or not (the one that triggered this
bug) and that is a good thing, because then the admin can decide if the
new one is better than the old, even considering the changes done to it.
> Please note that the release team agrees with me, and that I had such
> issues in the past, so I believe I'm right.
> Openstack-devel mailing list
> Openstack-devel at lists.alioth.debian.org
--------------------- Ola Lundqvist ---------------------------
/ opal at debian.org Annebergsslingan 37 \
| ola at inguza.com 654 65 KARLSTAD |
| http://inguza.com/ +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
More information about the Openstack-devel