On Tue, 25 Apr 2006 09:47:55 +0100 Stephen Gran wrote: > 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.
I do agree that lessdisks-terminal is _not_ a candidate as owner of any of those files, so should be fixed to not violate policy. What I did above was elaborate on wether those other packages mentioned also violates policy. Or put differently: The optimal for lessdisks-client was to work correctly when installed - moving the needed configuration changes into an installation script run by the local user is a bad hack: Being able to reverse the proces simply by removing the package again would be best. So I want to understand exactly which package then owns the files that lessdisks-client is not allowed to mess with on its own - in order to either conflict with those packages or (preferrable, but also slower to implement) help implement an interface for editing the files. If e.g. /etc/kernel-img.conf is owned by kernel-package then great - I don't even need to understand the interface mentioned by Manoj, but can simply conflict with that package instead. That's policy compliant, but hey - what about the kernels then? It is only a corner case that they write to that file, but still...? > > > 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. Nope - it means that _either_ we'd rather be without the package for the next release, _or_ we'd rather delay the release to get the problem fixed. > I doubt that that's true for the kernel. I honestly do believe that we want to resolve such problem before next release. And even if it turns out to be too tricky to solve or judged too much a corner case, there's also the option of tagging the bug as etch-ignore. > 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. You tell me that some bugs are inapropriate for the BTS? I know about the non-disclosure of some security fixes, but those aside I disagree. > > > > > 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. Sorry - I understand you now - and that example is quite comparable: Similar to /etc/inittab, None of the packages assumed owning the file does properly remove the file on package purge. > > > 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. No, not perfect, but enough to change this bugreport into a low-priority one about implementing a better approach when resolved how to actually do that (which may involve filing bugreports against those packages similarly violating policy). - 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
pgpFrkU7uwNs9.pgp
Description: PGP signature
