This one time, at band camp, Jonas Smedegaard said: > On Mon, 24 Apr 2006 14:44:06 +0100 Stephen Gran wrote: > > 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).
OK, I think this is a fairly straight forward test - does lessdisks-terminal in any way maintain either kernel-img.conf or inittab (ship a manpage, related infrastructure, file creation/deletion handling)? If not, then your package doesn't own the file, and can't modify it except via a helper script. I'm not trying to be brusque, I just want to cut to the chase here. > > 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 ;-). No, You misunderstand me. An RC bug means, by definition, that we would rather remove the package from the next stable release rather than ship it with this problem. I doubt that that's true for the kernel. There are other channels for fixing bugs than clogging up the release team's queue with things they are just going to override if they have to get a kernel image into etch. > > 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"? Taht paragraph is about inetd.conf. It is an example of a parallel situation that is handled correctly. Sorry if I wasn't clear. > 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. Good. > > 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. If I undersatnd correctly, you want to move the config file editing out of postinst into something the admin invokes? That would be perfect, thank you. Take care, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
