From: Stephen Gran <sgran@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: lessdisks-terminal: modifies /etc/kernel-img.conf in postinst
Date: Sun, 29 Jan 2006 15:34:58 +0000
Package: lessdisks-terminal; Maintainer for lessdisks-terminal is (unknown);
Reported by: Stephen Gran <sgran@debian.org>
Date: Sun, 29 Jan 2006 15:48:04 UTC
Severity: serious
Done: Amaya <amaya@debian.org>
Bug is archived. No further changes may be made.
View this report as an mbox folder, status mbox, maintainer mbox
Report forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
New Bug report received and forwarded. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: lessdisks-terminal
Severity: serious
Justification: Policy 10.7.4
debian/lessdisks-terminal.postinst:
if ! egrep "postinst_hook|postrm_hook" /etc/kernel-img.conf; then
echo "postinst_hook = /usr/sbin/update-lessdisks-kernels" >> /etc/kernel-img.conf
echo "postrm_hook = /usr/sbin/update-lessdisks-kernels" >> /etc/kernel-img.conf
fi
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-amd64-k8
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Bill Allombert <allomber@math.u-bordeaux.fr>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #10 received at 350407@bugs.debian.org (full text, mbox, reply):
On Sun, Jan 29, 2006 at 03:34:58PM +0000, Stephen Gran wrote: > Package: lessdisks-terminal > Severity: serious > Justification: Policy 10.7.4 > > debian/lessdisks-terminal.postinst: > if ! egrep "postinst_hook|postrm_hook" /etc/kernel-img.conf; then > echo "postinst_hook = /usr/sbin/update-lessdisks-kernels" >> /etc/kernel-img.conf > echo "postrm_hook = /usr/sbin/update-lessdisks-kernels" >> /etc/kernel-img.conf > fi Hello Stephen and Jonas, This bug is marked RC since sometime now, we need to move on. Note that debian/lessdisks-xterminal.postinst has a similar bug: debian/lessdisks-xterminal.postinst: echo "$inittab_line" >> /etc/inittab Is it not possible to move such tweak to lessdisks-setup so they are performed by action of the user on the server rather than mere installation of the package on the client? Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here.
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #15 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sat, 22 Apr 2006 01:35:55 +0200 Bill Allombert wrote: > This bug is marked RC since sometime now, we need to move on. Yep - thanks for pushing: I'm looking at it now :-) > Note that debian/lessdisks-xterminal.postinst has a similar bug: > > debian/lessdisks-xterminal.postinst: > echo "$inittab_line" >> /etc/inittab Thanks for noting! > Is it not possible to move such tweak to lessdisks-setup so they are > performed by action of the user on the server rather than mere > installation of the package on the client? Not lesdisks-setup. That script applies to each diskless terminal. But moving them to /usr/share/lessdisks/lessdisks-terminal-install seems to make good sense. - 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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #20 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sat, 22 Apr 2006 01:35:55 +0200 Bill Allombert wrote: > On Sun, Jan 29, 2006 at 03:34:58PM +0000, Stephen Gran wrote: > > Package: lessdisks-terminal > > Severity: serious > > Justification: Policy 10.7.4 > > > > debian/lessdisks-terminal.postinst: > > if ! egrep "postinst_hook|postrm_hook" /etc/kernel-img.conf; > > then echo "postinst_hook = /usr/sbin/update-lessdisks-kernels" > > >> /etc/kernel-img.conf echo "postrm_hook > > >> = /usr/sbin/update-lessdisks-kernels" >> /etc/kernel-img.conf > > fi > Note that debian/lessdisks-xterminal.postinst has a similar bug: > > debian/lessdisks-xterminal.postinst: > echo "$inittab_line" >> /etc/inittab Hi Bill and Stephen, What exactly is the policy violation here? Policy 10.7.4 forbids packaging scripts to mess with conffiles of other packages. But /etc/kernel-img.conf and /etc/inittab is not conffiles. Policy 10.7.4 also mandates shared configuration files to be owned by only one package. But it is not clear to me which single package that should be (that I should then file bugs against about an interface for messing with its configuration files). The packages sysvinit and a bunch of kernel packages seem to be kandidates, but looking at their packaging scripts they too seem to treat the configuration files as alien. - 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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #25 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
This one time, at band camp, Jonas Smedegaard said:
> On Sat, 22 Apr 2006 01:35:55 +0200 Bill Allombert wrote:
>
> > On Sun, Jan 29, 2006 at 03:34:58PM +0000, Stephen Gran wrote:
> > > Package: lessdisks-terminal
> > > Severity: serious
> > > Justification: Policy 10.7.4
> > >
> > > debian/lessdisks-terminal.postinst:
> > > if ! egrep "postinst_hook|postrm_hook" /etc/kernel-img.conf;
> > > then echo "postinst_hook = /usr/sbin/update-lessdisks-kernels"
> > > >> /etc/kernel-img.conf echo "postrm_hook
> > > >> = /usr/sbin/update-lessdisks-kernels" >> /etc/kernel-img.conf
> > > fi
>
> > Note that debian/lessdisks-xterminal.postinst has a similar bug:
> >
> > debian/lessdisks-xterminal.postinst:
> > echo "$inittab_line" >> /etc/inittab
>
> Hi Bill and Stephen,
>
> What exactly is the policy violation here?
>
> Policy 10.7.4 forbids packaging scripts to mess with conffiles of other
> packages. But /etc/kernel-img.conf and /etc/inittab is not conffiles.
This is the section that is relevant:
If it is desirable for two or more related packages to share a
configuration file and for all of the related packages to be able
to modify that configuration file, then the following should be done:
One of the related packages (the "owning" package) will manage
the configuration file with maintainer scripts as described in the
previous section.
The owning package should also provide a program that the other
packages may use to modify the configuration file.
The related packages must use the provided program to make any desired
modifications to the configuration file. They should either depend
on the core package to guarantee that the configuration modifier
program is available or accept gracefully that they cannot modify
the configuration file if it is not. (This is in addition to the
fact that the configuration file may not even be present in the
latter scenario.)
Note that it talks about configuration files, not just dpkg conffiles.
Your package directly modifies another package's configuration file,
instead of using an interface to do so.
The fact that there is, as afar as I know, no current interface, makes
this trickier to solve on your own, I understand ;(
> Policy 10.7.4 also mandates shared configuration files to be owned by
> only one package. But it is not clear to me which single package that
> should be (that I should then file bugs against about an interface for
> messing with its configuration files). The packages sysvinit and a
> bunch of kernel packages seem to be kandidates, but looking at their
> packaging scripts they too seem to treat the configuration files as
> alien.
Probably bugs against kernel-package (for kernel-img.conf) for an
interface script is sufficient to get this part of the bug closed.
I am not sure how to handle the inittab stuff, as IIRC there are several
initscripts implementations floating around out there (but maybe only
sysvinit handles inittab?) I just don't know the answer.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #30 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sun, 23 Apr 2006 11:44:59 +0100 Stephen Gran wrote: > This is the section that is relevant: [snip text already summarized in the quote of me further below] > Note that it talks about configuration files, not just dpkg conffiles. Yes. I am well aware of that. > 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? > > Policy 10.7.4 also mandates shared configuration files to be owned > > by only one package. But it is not clear to me which single package > > that should be (that I should then file bugs against about an > > interface for messing with its configuration files). The packages > > sysvinit and a bunch of kernel packages seem to be kandidates, but > > looking at their packaging scripts they too seem to treat the > > configuration files as alien. > > Probably bugs against kernel-package (for kernel-img.conf) for an > interface script is sufficient to get this part of the bug closed. 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. Being (small) part of the kernel team I suspect solving this is difficult: The only sane approach I can see is to have a separate "kernel-install-helper" own the file and provide an interface for both kernel packages and various kernel helper tools - including not only ramdisk generators but also like here more general bootup environment helpers. The wiki page http://wiki.debian.org/FlexibleKernelHandling is a proposal for this. Manoj, maintainer of kernel-package, haas shown interest in the approach, and (if I understand correctly) welcomes concrete implementations of such kernel-install-helper (which I have failed to provide so far myself: help is much appreciated). > I am not sure how to handle the inittab stuff, as IIRC there are > several initscripts implementations floating around out there (but > maybe only sysvinit handles inittab?) I just don't know the answer. 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). 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. Also, it seems to me that policy could use a clarification of how to indicate ownership... - 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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #35 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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. If that's not the case, I apologize. > > > 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. > 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. 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. > The wiki page http://wiki.debian.org/FlexibleKernelHandling is a > proposal for this. Manoj, maintainer of kernel-package, haas shown > interest in the approach, and (if I understand correctly) welcomes > concrete implementations of such kernel-install-helper (which I have > failed to provide so far myself: help is much appreciated). Yes, that looks quite reasonable. > > I am not sure how to handle the inittab stuff, as IIRC there are > > several initscripts implementations floating around out there (but > > maybe only sysvinit handles inittab?) I just don't know the answer. > > 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. There may be other init systems that also want to own the file, but that's a question for another day, I think. 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. > 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. > Also, it seems to me that policy could use a clarification of how to > indicate ownership... Perhaps. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #40 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #45 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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: > > > If that's not the case, I apologize. > > No need for that - I wasn't offended :-) Glad to hear it. > > 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. [...] > ...IMHO, that is. Please let me know if you find my arguments bogus > :-) Fair enough. > > 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. That may be. 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 :) 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. > > 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 :-) Yes, I think we are as well. There are plenty of buggy packages in Debian, my own being no exception, in all likelihood. But let's take them on one bug report at a time :) > > 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. Ah, OK - this is exactly what I was trying to get at. Maybe I should have been more clear up front. Sorry about that. > 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. > > > 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. 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. For sysvinit, I have no idea. If there are other init implementations (at the moment I only see minit as an alternative, but ISTR a runit or something package at some point as well) then it will need to be worked on in coordination with all of them, so there is a generic interface to a file that may have different formats. But in general, 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. Just my thoughts for now. Take care, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #50 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #55 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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 | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Manoj Srivastava <srivasta@ieee.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #60 received at 350407@bugs.debian.org (full text, mbox, reply):
The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.kernel as well.
Hi,
lessdisks-terminal should not muck with /etc/kernel-img.conf,
it should be dumping things in /etc/kernel/post{inst,rn}.d/
directories.
manoj
--
You will outgrow your usefulness.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #65 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
This one time, at band camp, Manoj Srivastava said:
> The following message is a courtesy copy of an article
> that has been posted to gmane.linux.debian.devel.kernel as well.
>
> Hi,
>
> lessdisks-terminal should not muck with /etc/kernel-img.conf,
> it should be dumping things in /etc/kernel/post{inst,rn}.d/
> directories.
Thanks for the infor, Manoj - I had no idea this facility was there.
Jonas, can you switch to using that, and then this part of the bug is
done.
Thanks,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Vagrant Cascadian <vagrant@freegeek.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #70 received at 350407@bugs.debian.org (full text, mbox, reply):
On Mon, Apr 24, 2006 at 11:16:03AM +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. If that's not the case, I apologize. > > > > > > 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. i have to disagree with this point. i do not have kernel-package installed on my system, but i have kernels installed which use /etc/kernel-img.conf, which was created by debian-installer. kernel-package is a helper utility to create kernel packages, not a package that you need installed on most systems, unless you need a custom kernel or are a kernel package maintainer. that said, i do agree that this probably shouldn't be in the postinst of the package :) live well, vagrant
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #75 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Tue, Apr 25, 2006 at 11:26:41AM -0700, Vagrant Cascadian wrote: > On Mon, Apr 24, 2006 at 11:16:03AM +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. If that's not the case, I apologize. > > > > 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. > i have to disagree with this point. i do not have kernel-package > installed on my system, but i have kernels installed which use > /etc/kernel-img.conf, which was created by debian-installer. > kernel-package is a helper utility to create kernel packages, not a > package that you need installed on most systems, unless you need a > custom kernel or are a kernel package maintainer. > that said, i do agree that this probably shouldn't be in the postinst of > the package :) s/shouldn't be/must not be/. You can't claim a well-known config file as yours just because there's no other package on the system that has done so; this is still a policy violation, both because it's not your config file to be editing, and because your postinst script doesn't respect a user's config on upgrades if the user has *removed* these update-lessdisk-kernels lines. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #80 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Tue, 25 Apr 2006 16:32:23 -0700 Steve Langasek wrote: > On Tue, Apr 25, 2006 at 11:26:41AM -0700, Vagrant Cascadian wrote: > > On Mon, Apr 24, 2006 at 11:16:03AM +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. If that's not the > > > case, I apologize. > > > > > > 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. > > > i have to disagree with this point. i do not have kernel-package > > installed on my system, but i have kernels installed which use > > /etc/kernel-img.conf, which was created by debian-installer. > > > kernel-package is a helper utility to create kernel packages, not a > > package that you need installed on most systems, unless you need a > > custom kernel or are a kernel package maintainer. > > > that said, i do agree that this probably shouldn't be in the > > postinst of the package :) > > s/shouldn't be/must not be/. You can't claim a well-known config > file as yours just because there's no other package on the system > that has done so; this is still a policy violation, both because it's > not your config file to be editing, and because your postinst script > doesn't respect a user's config on upgrades if the user has *removed* > these update-lessdisk-kernels lines. I believe we all agree that lessdisks-terminal violates Debian Policy (section 10.7.4): I'll make sure to fix that! The reason for my pointing to this bugreport on the debian-kernel mailinglist is that the discussion here seems to raise other issues (and Stephen is hesitant to file RC bugreports against the kernels). Noone has so far argued against linux-2.6 having RC bugs, so I might just take the heat of filing those bugreports myself (forking this one). - 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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #85 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Wed, Apr 26, 2006 at 12:52:54PM +0200, Jonas Smedegaard wrote: > On Tue, 25 Apr 2006 16:32:23 -0700 Steve Langasek wrote: > > > kernel-package is a helper utility to create kernel packages, not a > > > package that you need installed on most systems, unless you need a > > > custom kernel or are a kernel package maintainer. > > > that said, i do agree that this probably shouldn't be in the > > > postinst of the package :) > > s/shouldn't be/must not be/. You can't claim a well-known config > > file as yours just because there's no other package on the system > > that has done so; this is still a policy violation, both because it's > > not your config file to be editing, and because your postinst script > > doesn't respect a user's config on upgrades if the user has *removed* > > these update-lessdisk-kernels lines. > I believe we all agree that lessdisks-terminal violates Debian Policy > (section 10.7.4): I'll make sure to fix that! > The reason for my pointing to this bugreport on the debian-kernel > mailinglist is that the discussion here seems to raise other issues > (and Stephen is hesitant to file RC bugreports against the kernels). > Noone has so far argued against linux-2.6 having RC bugs, so I might > just take the heat of filing those bugreports myself (forking this one). Looking at the k-p-generated postinst scripts, I see a single edge case in which the script will offer to write out /etc/kernel-img.conf if it doesn't exist. Is this what you're referring to? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #90 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
This one time, at band camp, Steve Langasek said: > On Wed, Apr 26, 2006 at 12:52:54PM +0200, Jonas Smedegaard wrote: > > The reason for my pointing to this bugreport on the debian-kernel > > mailinglist is that the discussion here seems to raise other issues > > (and Stephen is hesitant to file RC bugreports against the kernels). To be more straight forward about it, I don't see that there's much utility in pretending we're going to release without a kernel. I would rather do this sort of infrastructural work in the kernel team channels directly. > > Noone has so far argued against linux-2.6 having RC bugs, so I might > > just take the heat of filing those bugreports myself (forking this one). > > Looking at the k-p-generated postinst scripts, I see a single edge case in > which the script will offer to write out /etc/kernel-img.conf if it doesn't > exist. Is this what you're referring to? That was what I saw, but since k-p generates the postinst that can, possibly, write the file, and also ships the manpage, I am torn between the two interpretations of 'expected use' vs. 'policy violation'. The edge case also seems to be a corner case for policy, at least from here. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #95 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #100 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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 | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Jonas Smedegaard <dr@jones.dk>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #105 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Thu, 27 Apr 2006 11:06:34 +0100 Stephen Gran wrote: > Are we done here? Ok. -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er n_r: http://www.shibumi.org/eoti.htm
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to vagrant@freegeek.org:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #110 received at 350407@bugs.debian.org (full text, mbox, reply):
On Tue, Apr 25, 2006 at 04:32:23PM -0700, Steve Langasek wrote: > On Tue, Apr 25, 2006 at 11:26:41AM -0700, Vagrant Cascadian wrote: > > On Mon, Apr 24, 2006 at 11:16:03AM +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. If that's not the case, I apologize. > > > > > > 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. > > > i have to disagree with this point. i do not have kernel-package installed on my system, but i have kernels installed which use /etc/kernel-img.conf, which was created by debian-installer. > > > kernel-package is a helper utility to create kernel packages, not a package that you need installed on most systems, unless you need a custom kernel or are a kernel package maintainer. > > > that said, i do agree that this probably shouldn't be in the postinst of > > the package :) > > s/shouldn't be/must not be/. You can't claim a well-known config file as > yours just because there's no other package on the system that has done so; > this is still a policy violation, both because it's not your config file to > be editing, and because your postinst script doesn't respect a user's config > on upgrades if the user has *removed* these update-lessdisk-kernels lines. i agree entirely. sorry for not using policy-compliant language in the context of an RC bug. i never meant to imply that it should somehow not be considered RC due to a technicality or some such. the point i was trying to make is that kernel-package shouldn't be considered an "owner" of /etc/kernel-img.conf (as defined in section 10.7.4 of debian-policy 3.6.2.2). live well, vagrant
Information forwarded to debian-bugs-dist@lists.debian.org, Jonas Smedegaard <dr@jones.dk>:
Bug#350407; Package lessdisks-terminal.
(full text, mbox, link).
Acknowledgement sent to Stephen Gran <sgran@debian.org>:
Extra info received and forwarded to list. Copy sent to Jonas Smedegaard <dr@jones.dk>.
(full text, mbox, link).
Message #115 received at 350407@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
This one time, at band camp, Jonas Smedegaard said: > On Thu, 27 Apr 2006 11:06:34 +0100 Stephen Gran wrote: > > > Are we done here? > > Ok. So, 3 months later. Any progress? -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
[signature.asc (application/pgp-signature, inline)]
Notification sent to Stephen Gran <sgran@debian.org>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #120 received at 350407-done@bugs.debian.org (full text, mbox, reply):
lessdisks-terminal is only found in oldstable. So these bug reports are stale and I am closing them. Thanks -- ·''`. A waste is a terrible thing to mind! : :' : `. `' `- Proudly running (unstable) Debian GNU/Linux
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Mon, 28 Apr 2008 07:26:30 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.