On Mon, Dec 11, 2006 at 02:00:06PM +0800, Thomas Goirand wrote: > Steffen Joeris wrote:
> > Your package edits conffiles with the maintainer scripts, which do not > > belong to your own package. This is a policy violation and results in > > an RC bug, sorry. > > Let me give you an example: > > You edit a lot in the php.ini , for instance adding some extensions. > The php debian package under Sarge had a nasty bug so mysql.so was not > inserted in the php.ini. If it's not in SID anymore, I'll skip that part > of the installer. But I know that also, the max memory for the apache > module and the max time of execution for the phpX-cli binary have to be > changed. Leaving it as-is would produce tons of requests in my public forum. > So I will: > - remove from sid the modifications for the .so in php if I see the php > packages really set the extension when installing. > - leave the modifications for max mem and max time. > Would it be better like that ? No. php.ini is still not yours to edit without prior coordination with the php package maintainers. > > As far as I know (but I am not that familiar with php stuff, so others > > are welcome to add more information) you can add a file and place it > > into the /etc/php[4|5]/conf.d/ directory. The added extensions are > > honoured by php and you have a lot of advantages. For instance when you > > purge your package the file will just be removed and therefore the > > extension will be removed as well. This is safe debian behavior, because > > with home-made shell scripting you can run into heaps of problems really > > fast, because you do not know what to expect from the php.ini and > > therefore your shell scripts might fail. However it is allowed to ship a > > configuration script which is NOT run by the maintainer script, but can > > be manually run by the user. I personally prefer to have a good > > documentation in the README.Debian file, so that the user can always > > check what needs to be done for configuration purpose. > > Please note that this is the example for the php.ini file, however there > > are other modifications, for instance the /etc/res I don't think this is > > the case.olv.conf file, please > > remove all of them from the postinst and make them policy compliant. > Modifying the resolve.conf is really needed, because all of the daemons > will run faster is using a caching name server. I don't think it's a > good idea not to query the installed bind server. That doesn't matter, you have no business imposing your preferences on users by editing this config file in a Debian package, either. > > Thanks in advance and have a nice sunday > Each of the modifications done by the control panel installer are really > needed. Please point to each of them and tell me what is wrong. > More generaly speaking the goal of that kind of software IS to manage > the daemon configurations, that is the ONLY goal of that kind of > programs, and that is NOT forbidden, as far as I could read. If you look > at the installer, it tries to modify the less possible in all the > configuration files. It's not overwriting anything, just doing the > modifications that are needed, and we tried the most we could to reverse > the changes when removing the panel. That being said, I'm always happy > to correct things so it integrates better. Changing config files from a web control panel is allowed. Changing them from within a package's *maintainer scripts* is not, and that's what this bug was filed about. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
