On Mon, 24 Apr 2006 11:16:03 +0100 Stephen Gran wrote: > 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.
I wasn't, but as should be clear from my other writing I was not aware of other methods to figure out the ownership either. > If that's not the case, I apologize. No need for that - I wasn't offended :-) I simply wanted to avoid wasting your time educating me on the difference between conffiles and configuration files. See #309871 and #311188 for earlier discussions on the matter that I've participated in. > > > 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. Right - a manpage can be interpreted as evidence of claiming ownership: No other package can provide same manpage without conflict. A sample file is no evidence: lessdisks providing a sample dhcpd.conf is not an indication of ownership - quite the contrary. Offering postinst hooks is not either: cdbs and debhelper does not own the configuration files they help maintain - each package is itself responsible for the choice of packaging methods and packaging tools. ...IMHO, that is. Please let me know if you find my arguments bogus :-) > > 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. Agreed - due to the manpage. > 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. As clarified above, I do believe so. > > 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. Well, we obviously agrees that sysvinit installs the file if not there already (that's what I wrote too). So does lessdisks-terminal :-) If "Installing a configuration file" means owning that file, then (as I wrote) it seems to me that sysvinit has other policy violations with its treatment of the configuration file. But I agree that we are getting astray here :-) > 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. Ah, so it's a shared configuration file, and there already is a defined method of interaction. I didn't know that. Which is the correct script to update inittab? And where can I read more about 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. Whatever the bug, it does not escape lessdisks, and it does relate to those other packages. And this discussion has helped me (if noone else) understand it better. Would you care to file those bugreports? I'd be happy to help resolve the issues, so please cc me if/when doing so, but am a slow writer, so would appreciate commenting rather than initiating. > > Also, it seems to me that policy could use a clarification of how to > > indicate ownership... > > Perhaps. Oh well. I didn't come much closer to a concrete suggestion, so if don't find it as obvious then let's just leave that for now. - 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
pgpSivVJKxuBK.pgp
Description: PGP signature
