Re: Policy process (was: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?)
On Sun, Sep 17, 2006 at 11:43:18AM -0700, Russ Allbery wrote: Copying the debian-policy list, since this conversation is basically about that. Kurt Roeckx [EMAIL PROTECTED] writes: I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Well, policy-process is still shipped with the debian-policy package, and my experience in the past is that when I follow that process, the changes go into Policy fairly quickly. Certainly seconding would show that someone reviewed the wording of my proposed ~ patch and has confirmed that it sounds like an accurate and implementable description of their behavior. Maybe Manoj could weigh in on how he sees the current process? That document says things like: The group that decides on policy should be the group of developers on the debian-policy mailing list, which is how it was always done; so the group of policy maintainers have no real power over policy. And that is not the impression I get from it. Also, I believe this has changed since they are now delegates of the DPL: http://lists.debian.org/debian-devel-announce/2005/07/msg2.html But it's unclear to me what this exactly means. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
[Mario Holbe] Is it? Yes, mounting tmpfs on /var/run/ and /var/lock/ is supposed to work, and packages not handling it need to be fixed. And as you can see in /etc/init.d/, quite a few packages got this right already. A few got still it haven't been adjusted to work like that, and we should get those fixed soon. So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. because if I would fix this, the submitter would surely come and require me to handle the magic disappearing of files under /usr/bin or directories under /usr/lib or whatever. If you believe this, you must have misunderstood what make /var/run/ and /var/lock/ special. They are supposed to be cleaned at boot, and this feature is not shared with /usr/bin/, /usr/lib or whatever. It is this property that make it OK to mount a tmpfs as /var/run/ and /var/lock/. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
Petter Reinholdtsen [EMAIL PROTECTED] writes: [Mario Holbe] So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. It would be quite nice to have more people participating in the Policy process in general. There are a fair number of proposals, but not a lot of people reading proposals, helping achieve consensus, and seconding. For example, I haven't gotten any responses to my patch to document ~ in version numbers, and I'm not sure what happened to the menu policy overhaul. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, Sep 17, 2006 at 09:55:46AM -0700, Russ Allbery wrote: Petter Reinholdtsen [EMAIL PROTECTED] writes: [Mario Holbe] So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. It would be quite nice to have more people participating in the Policy process in general. There are a fair number of proposals, but not a lot of people reading proposals, helping achieve consensus, and seconding. For example, I haven't gotten any responses to my patch to document ~ in version numbers, and I'm not sure what happened to the menu policy overhaul. I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Policy process (was: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?)
Copying the debian-policy list, since this conversation is basically about that. Kurt Roeckx [EMAIL PROTECTED] writes: I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Well, policy-process is still shipped with the debian-policy package, and my experience in the past is that when I follow that process, the changes go into Policy fairly quickly. Certainly seconding would show that someone reviewed the wording of my proposed ~ patch and has confirmed that it sounds like an accurate and implementable description of their behavior. Maybe Manoj could weigh in on how he sees the current process? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy process (was: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?)
On Sun, Sep 17, 2006 at 11:43:18AM -0700, Russ Allbery wrote: Kurt Roeckx [EMAIL PROTECTED] writes: I don't think policy changes need to be seconded. We have a policy team that should decide on what comes in policy and what not. Although, it more looks like it's just 1 person doing all the work. I sometimes feel that they go to slow which changing things, and I'm not really sure it's a good or bad thing. Some of those currently open bugs against the policy package, like your ~ in version numbers, really shouldn't be a problem to get into the policy. I don't think anybody has a problem with it. I think it's just that no new version of the policy has been made yet. Well, policy-process is still shipped with the debian-policy package, and my experience in the past is that when I follow that process, the changes go into Policy fairly quickly. Certainly seconding would show that someone reviewed the wording of my proposed ~ patch and has confirmed that it sounds like an accurate and implementable description of their behavior. Hello, As a debian-policy denizen, I am quick to second proposal I like. However, here this a purely the description of what dpkg do. What matter is whether the text is faithful to the implementation, not whether I like it or not, and i don't feel qualified to vet the text. However, there is at least 2 dpkg maintainers, they are very qualified to check it, and I expected they would second the proposal. If they did not see it, I suggest to forward it to them asking for review and second. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, 17 Sep 2006 the mental interface of Russ Allbery told: Petter Reinholdtsen [EMAIL PROTECTED] writes: [Mario Holbe] So, as long as the Debian policy doesn't handle this, I agree that we should update the policy to document this fact. It would be quite nice to have more people participating in the Policy process in general. There are a fair number of proposals, but not a lot of people reading proposals, helping achieve consensus, and seconding. For example, I haven't gotten any responses to my patch to document ~ in version numbers, and I'm not sure what happened to the menu policy overhaul. I've experienced problems using tilde in Filenames: The problem is caused by the fact that there is a ~ in the directory name. Libtool uses ~ as a separator. [1] [1]http://autoconf-archive.cryp.to/patch_libtool_changing_cmds_ifs.html Elimar -- Alles was viel bedacht wird ist bedenklich!;-) Friedrich Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sun, 17 Sep 2006, Mario 'BitKoenig' Holbe wrote: cons, and issues and difficulties... would it probably make sense to split the discussion about /var/x being able to be tmpfs'ed out and just choose another location for the intended place-to-store-things-while- nothing-else-is-mounted-rw? Yes. I have just done that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
[Kurt Roeckx] I'm not really sure what the right thing to do is. Maybe the FHS should be made clear on what you can expect from /var/run. I believe it is quite clear that the sysadmin is allowed to use tmpfs as /var/run/, and that packages which fail to support this has a bug. To test the impact, I had a look at the packages installed on my test machines, as well as some of the packages listed in the file on merkel: OK: alsa-base 1.0.12-1: init.d script creates /var/run/alsa/ apache2-common 2.0.55-4.2: init.d script creates /var/run/apache2/ autofs 4.1.4-11: init.d script creates /var/run/autofs/ cupsys 1.2.3-1: init.d script creates /var/run/cups/ dbus 0.92-2: init.d script creates /var/run/dbus/ dirmngr 0.9.6-1: init.d script creates /var/run/dirmngr hal 0.5.7.1-2: /etc/dbus-1/event.d/20hal creates /var/run/hal/ mpd 0.11.5-9: package no longer uses subdir in /var/run/ openssh-server 4.3p2-3: init.d script creates /var/run/sshd/ postgresql 7.5.21: package no longer uses subdir in /var/run/ ssh 4.3p2-3: Just a dummy package Not checked, missing or uninstallable in sid hotplug: /var/run/usb dbus-1: /var/run/dbus Unsure slapd 2.3.25-1: Uses /var/run/slapd/, but not sure if it creates it. Need fix: pppconfig 2.3.14: /etc/ppp/ip-*.d/0dns-* expect /var/run/pppconfig to exist greylistd 0.8.3.1: init.d expect /var/run/greylistd pident 3.0.19.ds1-1: store pid in /var/run/identd/ but is started via inetd! clamav-daemon 0.88.4-2: init.d script expect /var/run/clamav/ crack-md5: Symlink /var/run/Crack/bin/debian, but nothing uses it? samba 3.0.23c-1: init.d script expect /var/run/samba/ Anyway, it would be useful if you didn't have to login on merkel to be able to see your list. I suggest you either submit those files to the BTS, or put it on people.debian.org or something. Here is the list of packages in sarge with directories in /var/run/, according to the file on merkel: alsa-base aolserver aolserver4 apache2-common asterisk autofs bacula-common bacula-director-common bacula-fd bacula-sd bincimap-run bind9 bindgraph binkd bld bnetd bopm caudium cfs chipcard-tools clamav-base courier-authdaemon courier-base courier-pcpcouriergraph crack crack-md5 cupsys cyrus21-common dancer-ircd dancer-services dbbalancer dbus-1 diald dirmngr distmp3 dovecot-common dropbear echolot fai firebird2-server-common freeradius gnunet greylistd gwtp hal hostapd hotplug inn inn2 ipband iptraf ircd-hybrid ircd-irc2 ircd-ircu isdnlog jabber jabber-common jftpgw john laptop-net libapache-mod-backhand linesrv lwresd lyskom-server mailman mailscanner messagewall mgetty-fax midentd mindi mixmaster mobilemesh mon mtink munin munin-node mysql-server mysql-server-4.1 nagios-common ndtpd newsx nut oinkmaster openct openntpd p3scan pgpool pipsecd pkcipe polipo postgresql pppconfig proftpd proftpd-ldap proftpd-mysql proftpd-pgsql psad pure-ftpd-common quagga quickml racoon radvd roundup roxen4 runit runit-run samba samhain scalemail screen sendmail-bin siproxd slapd slidentd slimp3 smokeping socklog-run spong-client spong-server spread ssh ssh-krb5 stunnel super sympa tetrinetx tiger totd twoftpd-run uml-utilities usbmount userv util-vserver vpnc vsftpd wackamole whereami Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Saturday 16 September 2006 23:07, Petter Reinholdtsen wrote: I agree that this need to be documented. We work on some notes for the sysvinit package, and will include it there. Sounds to me like this belongs in policy. pgpTZyxVfGvin.pgp Description: PGP signature
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 09:38:07PM +0200, Petter Reinholdtsen wrote: [Kurt Roeckx] I'm not really sure what the right thing to do is. Maybe the FHS should be made clear on what you can expect from /var/run. I believe it is quite clear that the sysadmin is allowed to use tmpfs as /var/run/, and that packages which fail to support this has a bug. However, that's not the same thing as saying it's ok for sysvinit to *make* /var/run a tmpfs on the admin's behalf. I think it's pretty clear that this violates the letter of the FHS, and such a change needs to be considered carefully. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-sysvinit-devel] Re: Moving /var/run to a tmpfs?
[Kurt Roeckx] The FHS says we can create directories under /var/run that are application specific. It also says that all files should be removed or truncated. It does not say anything about directories being removed. It does not say they will stay either, though it specifies Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. I guess it is is unspecified if directories are persistent or not. And as some have pointed out, there are sysadmins already mounting /var/run/ as tmpfs, and it is a bug with the package if it does not work properly. If I create a directory in /var/run, I expect it to stay there. And if I can't expect that, I'd like to see that documented somewhere. I agree that this need to be documented. We work on some notes for the sysvinit package, and will include it there. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
