On 12/19/2013 03:43 AM, Gaudenz Steinlin wrote: >> This is some remaining from before I restarted working on the packaging >> of OpenStack, and a feature which I just didn't touch. Each time I see >> it, I think I should kill this functionality. Would you agree (and the >> rest of the packaging team) that it's useless, since Debian has all the >> needed tools to do that? >> >> If nobody complains about it, I'll kill this thing completely, and will >> do the same for Nova. > > I'm not exactly sure what you are refering here with "this thing". If > you mean the part that you can enable service in /etc/default/* files, > then I completely agree. I just did not mention this because it's not > really part of the bug, but IMO this is a bad way to control if a > service is started or not, there are much better ways to not start a > service (ie runlevels) and at the same time keeping the possiblity of > starting it from the command line with the normal init script. > > So I'm very much in favor of this. But this does only work around this > instance of the bug and not solve the deeper issue which is somewhere > inside the pile of shell code in openstack-pkg-tools.
The problem doesn't lie at all in openstack-pkg-tools, which in itself is policy compliant. Read what it does if you aren't convinced. While reworking the Cinder packages, I just re-factored a bit that part for the start-cinder thing which reads config files, though I should have just rework it completely in the normal way, or killed it all together directly. Note that there must be the same problem in Nova, which I will address right away (by killing the useless default file as well). > And AFAIK this is > code you wrote and not code that existed before you started working on > the openstack packages. Unfortunately, for that bit of code, no. It was there before, I just re-used a function of openstack-pkg-tools to replace the bits that were there, though it wasn't policy compliant to begin with. > I think you should also fix this bug or it will probably reappear in > some form. The bug is somewhere hidden in the parsing of the > cinder-common default file. Rest assured that this isn't the case in other bits of the code, which are properly reading configuration files before the initialization of the debconf screens, just as the Debian policy tells. If you find some cases where that's not the case, then this must be specific to some very small parts of the code. Probably the thing with Horizon needs some checkings, not sure. But that's the only part which I'm not entirely sure if the logic is policy compliant. I've killed the start-cinder bits, and will reupload with it soon. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org