On Mon, 24 Apr 2006 14:44:06 +0100 Stephen Gran wrote: > This one time, at band camp, Jonas Smedegaard said: > > On Mon, 24 Apr 2006 11:16:03 +0100 Stephen Gran wrote: > > > This one time, at band camp, Jonas Smedegaard said:
> > > 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. ...on the other hand, it does not have to be evidence of that: Providing a manpage does not _imply_ an ownership claim. It can also be only providing the definition/policy of an _optional_ configuration file not owned by _any_ package. Debian Policy 10.7.3 only mandates maintainance of configuration files if _required_ for the package to work correctly: > If the existence of a file is required for the package to be sensibly > configured it is the responsibility of the package maintainer to > provide maintainer scripts which correctly create, update and maintain > the file and remove it on purge. It makes sense to equal the "maintainance" requirement in 10.7.3 with the "ownership" requirement in 10.7.4: Debian Policy 10.7.4 can be interpreted as mandating no _more_ than one package owning a configuration file (rather than _always_ one owner). This interpretation fits kernel-img.conf: The packages most obvious as "owner" of the configuration file all works fine without the file in place. And there's no single candidate for an owning package. I do feel that such interpretation is problematic, however: Even when several main packages (kernel-package, linux-2.6, kernel-image-2.4.27-i386) agree to share a configuration file with none of them requiring it, how do then an additional package (lessdisks-terminal) treat the situation if requiring the file to exist? (and also, judging from comments in postinst it seems that linux-2.6 really requires the file when using symlinks). These thoughts are thrown here only for the record - see bottom of this mail... > So far, we have been pretty lenient WRT kernel images (and > kernel-package) and policy. I am a little leery of opening an RC bug > on them right now, as I think vorlon might beat me with a heavy stick > for making his life harder than it already is :) Hmm - so RC bugs should be avoided if annoying the maintainer? Sounds like a violation of "we won't hide problems" - even with the narrow interpretation of only applying to the BTS ;-). > I do think it's something worth discussing within the kernel team, > however, and you seem better placed than I am to start that > discussion. I am happy to help with code, but I don't know the guts > of kernel package all that well, so it may take longer than is worth > it for me to come up to speed with all the hooks and options that a > helper script would need to know about. > > > 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. > > Which is the correct script to update inittab? And where can I read > > more about it? > > As far as I know, again, there is none. I think this is such a rare > need that no one has bothered to write one. Ahem, then hwat do you mean by "and there is a helper script to update it"? And what do you mean by "clearly is owned"? (sorry to be so thick-headed) > > > I am in favor of filing bugs on kernel-package and/or sysvinit > > > for helper scripts to update their config files, though. > > Would you care to file those bugreports? > As I said, probably talking about the issue (for kernel-package, at > least) before bug filing is going to be most helpful. I don't want to > get to the point of filing a bunch of bugs that don't have a clear > goal behind them, and since I don't really know the guts of > kernel-package that well, that is roughly what I'd end up doing. > > I think having a chat with manoj about what parts of the config file > should be exported and writable by a helper script is a good first > step, then from that, the design of a helper script should come pretty > quickly. I'll make Manoj and the rest of the kernel team aware of this discussion, but feel that I have spent enough of his time discussing the kernel-install-helper idea without taking the required time and effort to actually make a proof of concept to move it further than just that: an idea. > the fast resolution for your package is to just stop writing to these > config files, and put a note in README.Debian that says roughly, "add > these two lines to this file, and this line to that file". That would > close this bug while the longer term correct solution is being worked > on. For the case of lessdisks-terminal, the messing with configuration files can even be moved to the user-invoked install routine instead, as mentioned early on in this thread. The best would be to not be messy at all, but I agree that sounds not possible for the short term. - 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
pgpQIBuQlDF2X.pgp
Description: PGP signature
