Hi Thomas 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 in nova-common.config. > 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. :-) // Ola > Thomas > > > > _______________________________________________ > Openstack-devel mailing list > openstack-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/openstack-devel > -- --------------------- Ola Lundqvist --------------------------- / o...@debian.org Annebergsslingan 37 \ | o...@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 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
