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.
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.
* Let think a moment of what involved solving this issue. It involves:
- Changing the patch for installation messages to reflect the /etc location
- Adding a patch for defining this MW_INSTALL_PATH
- Changing the documentation for reflecting this new path too
- Changing the automated update script
And, perhaps the most important:
- Add an updating code which detects wether the configuration is in /etc or
in /var and apply the good changes. Of course, in order not to blow again any
file, this script as to be started before the packages files are copied.
- Also, you may add an advice to the administrator via debconf so that he is
aware of this change in his configuration.
Now that would let a package for etch that would have a lot of debconf, script
and code specialised for an issue that will not appear for any fresh install
from the forthcoming debian stable and solves an issue that *I* feel not that
important.
Now ok, I am not a blocker, if others come and say that it has to be solved
I'll do it of course, but it is not my opinion. In particular, I would like
to hear for Marc and perhaps the release team on what I wrote above.
Romain
