On Sun, 23 Apr 2006 11:44:59 +0100 Stephen Gran wrote: > This is the section that is relevant:
[snip text already summarized in the quote of me further below] > Note that it talks about configuration files, not just dpkg conffiles. Yes. I am well aware of that. > Your package directly modifies another package's configuration file, > instead of using an interface to do so. Please clarify: Which _single_ package do you believe to own those configuration files in question? > > Policy 10.7.4 also mandates shared configuration files to be owned > > by only one package. But it is not clear to me which single package > > that should be (that I should then file bugs against about an > > interface for messing with its configuration files). The packages > > sysvinit and a bunch of kernel packages seem to be kandidates, but > > looking at their packaging scripts they too seem to treat the > > configuration files as alien. > > Probably bugs against kernel-package (for kernel-img.conf) for an > interface script is sufficient to get this part of the bug closed. kernel-package does not own /etc/kernel-img.conf, I believe. It only provides an interface for other packages (like linux-2.6) to adopt to mess with the (non-owned, it seems) file. Being (small) part of the kernel team I suspect solving this is difficult: The only sane approach I can see is to have a separate "kernel-install-helper" own the file and provide an interface for both kernel packages and various kernel helper tools - including not only ramdisk generators but also like here more general bootup environment helpers. The wiki page http://wiki.debian.org/FlexibleKernelHandling is a proposal for this. Manoj, maintainer of kernel-package, haas shown interest in the approach, and (if I understand correctly) welcomes concrete implementations of such kernel-install-helper (which I have failed to provide so far myself: help is much appreciated). > I am not sure how to handle the inittab stuff, as IIRC there are > several initscripts implementations floating around out there (but > maybe only sysvinit handles inittab?) I just don't know the answer. Same here: It does not seem from the packaging scripts of sysvinit that that package considers itself owner of that file: It does not treat it as a conffile, only installs it if not there already, and does not remove it on purge (which may never be tested in reality, since the package is essential). I don't mean to say that there's no bug, but that I believe the bug is a different one: Noone claims ownership of those configuration files, so it is uncertain what package to either bug about an interface or to conflict against. If you agree with my viewpoint, we should probably rename this bugreport and clone it to other packages involved. Also, it seems to me that policy could use a clarification of how to indicate ownership... - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er n_r: http://www.shibumi.org/eoti.htm
pgpGhzpXV5ZNT.pgp
Description: PGP signature
