Hello, thanks for this mail.
Steffen Joeris wrote: > Hi mate > > 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 ? > 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. > Thanks in advance and have a nice sunday > > Friendly, > Steffen 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. Expect a new upstream stable version soon, as I rewrote all forms drawings last week. This new code is a lot safer, because more systematic I think. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
