This one time, at band camp, Jonas Smedegaard said: > On Tue, 25 Apr 2006 09:47:55 +0100 Stephen Gran wrote: > > > 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.
Good. > What I did above was elaborate on wether those other packages mentioned > also violates policy. It appears that there is a corner case, that, when viewed from a certain angle, might violate policy. The situation is unclear to me, but if you think it's more clear, feel free to file bugs or do whatever you like. > 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...? Didn't manoj tell you explicitly how to interface with the scripts? I thought he pointed you to using the hooks directories. This means you don't need to conflict with anything. > > 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. As I said, I am not sure it is a bug for the kernels. It is certainly interesting, but they are all using a common infrastructure handed to them by a package that writes their postinst's, so it could be read several ways. Only one way makes it an RC bug, and the time wasted arguing (on this bug alone, not to mention any further ones that might get opened) seems to me to be wasting more time than just fixing _this_ bug and moving on. > > 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. I am saying that some things that are unclear but may not be bugs may be better handled in an open discussion, rather than throught the BTS. > > 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). So, manoj has told you can use the hooks directories from your maintainer scripts. That solves any problems with kernel-img.conf, as far as I can see. As for inittab, well, you're just going to have to stop writing to it, unless you want to conflict with init and take responsibility for the file ;) I think that covers everything. Are we done here? -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
