On Tue, Feb 06, 2007 at 12:05:46PM +0100, Romain Beauxis wrote: > Le mardi 6 février 2007 02:47, Philippe Cloutier a écrit : > > >If you wish to add a RC bug more to debian, please ask to the release > > > managers if they feel that this should be solved for debian etch.
> > Release team: I believe that #388616 should be upgraded back to serious. > > Please state that you agree with Romain if the report shouldn't be > > upgraded back to serious. > Ok, right I acknowledge the answer from the release team. > Now here is my anwser: > I do not feel apropriate to correcet this bug and here is why : > * The configuration file is not located in /etc and this is a policy > violation, that is a fact. However, this configuration file is linked in /etc > so that the administrator can locate it when he needs it. > * Reports claiming that their configuration files had been deleted by update > were either users of the previous packaging or users that had a wrong > documentation. Since those bugs were posted, I corrected documentation. Also, > on a fresh install, messages after install clearly ask for puting this file > in /var/lib/mediawiki1.7 > * The reason why I did this rely on this header, on the fresh configuration > file: > "if( defined( 'MW_INSTALL_PATH' ) ) { > $IP = MW_INSTALL_PATH; > } else { > $IP = dirname( __FILE__ ); > }" > From this point, the $IP, which is later taken as include path, > reflects /etc/mediawiki1.7 as soon as the configuration file is located > in /etc: php resolves dirname by the real directory name and not the name for > the directory of the link. > * I choosed to put the file to /var/lib because I misread the policy, and > because, under this bad assumption, I choosed the solution which involved the > less patching. Obviously, adding a > define(MW_INSTALL_PATH,"/var/lib/mediawiki1.7"° on top of the file is the > good solution. It is also what is done in my next 1.9 package. Hmm, unfortunate. > Now that I have cleared the origins of the bug, let's explain why I do not > feel appropriate to resolve it: > * To me the violation is not that severe since the file is located in /etc > after all. I understand that others may not think the same way, but that is > my point. No, policy requires that the *file* be stored in /etc, not a symlink *to* the file. So this is still a policy violation. Under the circumstances, I would be willing to grant an etch-ignore exception for the file location. If the location of the file is still causing upgrade errors (which seems possible, since the symlinks under /etc/mediawiki1.7 are not conffiles and therefore may overwrite a user's config), that would be more than just a technicality, and I wouldn't grant an etch-ignore exception for that. -- 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/