On Sun, May 29, 2005 at 09:43:13PM +0200, Petter Reinholdtsen wrote: > [Jonas Smedegaard] > > It is a violation of Debian Policy to mess with conffiles of other > > packages, and http://release.debian.org/sarge_rc_policy.txt section > > 3 adds this: > Debian policy section 10.7.4 (Sharing configuration files) reads: > The maintainer scripts must not alter a conffile of any package, > including the one the scripts belong to. > The base-config scripts are not maintainer scripts, so the behaviour > of debian-edu-config do not break the written policy. So the sarge RC > policy "clarification" is clearly a more extended rule than the one in > the current policy. > The new "clarification" seem to forbid all scripts that can edit > conffiles. Is this the correct interpretation? > (And yes, I believe we need to find a better way to handle > configuration in debian-edu, but while we wait, I see no better way to > do it than the current mechanism. And I believe it is not breaking > policy as it is written in the Debian Policy Manual today. > It would be interesting to know which packages conffiles we affect, to > have a work list of packages we need to make more configurable. It's my understanding that policy's prohibition on editing conffiles from maintainer scripts is intended to extend to any programs that are called from maintainer scripts, and the sarge RC policy clarifies this: you are not allowed to cause any package's conffiles to be edited in the process of installing or removing a package. The sarge RC policy says that the only correct way to modify a conffile is "the user running an editor specifically". This doesn't say that it must be a *text* editor; other specialized editors also exist, and I don't have a problem with such tools as long as they're not called on the user's behalf by the package. OTOH, base-config isn't as clear-cut because nothing is done in the maintainer scripts, but base-config itself is invoked for the user at install time. I realize that debian-edu-config is something of a special case, because of its narrow application. I don't think that Debian-Edu should get a free pass for violating policy, but I also don't think that there's much risk of this issue affecting people who aren't installing debian-edu explicitly, so it doesn't seem to make much difference to their net experience whether deiban-edu-config is allowed in sarge or not. So unless someone else on the release team objects, I think I'm going to tag this bug sarge-ignore. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature