This one time, at band camp, Jonas Smedegaard said: > On Sun, 23 Apr 2006 11:44:59 +0100 Stephen Gran wrote: > > > Note that it talks about configuration files, not just dpkg conffiles. > > Yes. I am well aware of that.
Ah, from the way you were talking about 'owning', I assumed you meant something like dpkg -S /etc/kernel-img.conf didn't show anything, so you were thinking it was unowned. If that's not the case, I apologize. > > > 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? It's fairly clearly kernel-package. kernel-package ships a sample config file, a man page, and is also responsible for the postinst hooks in the kernel images that mess with kernel-img.conf. > 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. I think this is incorrect, sorry. I think it is both fairly clear kernel-package owns the file in question, and that it does not provide an interface for updating the file. Right now, the kernel images just open it and write to it if it's not there. Since their postinst scripts come from kernel-package itself, I am not sure if that's a policy violation or not. But it certainly is for other packages that don't use kernel-package generated maintainer scripts. > 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). Yes, that looks quite reasonable. > > 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). Well, I see on my system: /var/lib/dpkg/info/sysvinit.postinst:if [ ! -f /etc/inittab ] /var/lib/dpkg/info/sysvinit.postinst: cp -p /usr/share/sysvinit/inittab /etc/inittab That means on my system at least, sysvinit owns the file /etc/inittab. There may be other init systems that also want to own the file, but that's a question for another day, I think. This is exactly like /etc/inetd.conf - no package 'owns' it in the dpkg -S sense, but it clearly is owned by whichever of the inetd implementations that you have installed, and there is a helper script to update it. > 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. I disagree. I think it is pretty straightforward which packages own the files in question. I am in favor of filing bugs on kernel-package and/or sysvinit for helper scripts to update their config files, though. > Also, it seems to me that policy could use a clarification of how to > indicate ownership... Perhaps. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
