Re: Can reports of serious policy violations be downgraded to important?
- To: Romain Beauxis <toots@rastageeks.org>
- Cc: Philippe Cloutier <philippe.cloutier.2@ulaval.ca>, 409434@bugs.debian.org, 388616@bugs.debian.org, debian-release@lists.debian.org, Marc Dequènes <duck@duckcorp.org>
- Subject: Re: Can reports of serious policy violations be downgraded to important?
- From: Steve Langasek <vorlon@debian.org>
- Date: Tue, 6 Feb 2007 16:25:41 -0800
- Message-id: <[🔎] 20070207002541.GM7153@mauritius.dodds.net>
- Mail-followup-to: Romain Beauxis <toots@rastageeks.org>, Philippe Cloutier <philippe.cloutier.2@ulaval.ca>, 409434@bugs.debian.org, 388616@bugs.debian.org, debian-release@lists.debian.org, Marc Dequènes <duck@duckcorp.org>
- In-reply-to: <[🔎] 200702061205.46880.toots@rastageeks.org>
- References: <45C4E887.3050502@ulaval.ca> <200702041952.48536.toots@rastageeks.org> <[🔎] 45C7DE30.4060009@ulaval.ca> <[🔎] 200702061205.46880.toots@rastageeks.org>
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.
vorlon@debian.org http://www.debian.org/
Reply to:
- Follow-Ups:
- Upgrade
- From: Filipus Klutiero <philippe.cloutier.2@ulaval.ca>