Re: [Pkg-sysvinit-devel] procps with pidof is released
On Tue, Dec 10, 2013 at 09:10:52AM +1100, Craig Small wrote: upstream what they are going to do? If they are going to keep pidof then the change is not required. If the projects plans is to Which I did. For the moment they have no plans moving pidof though they don't seem terribly fussed either way (that's my read of it anyhow). What I have done is used the --disable-pidof flag in procps configure step. This means procps does *not* have pidof and it can remain in sysvinit-tools for the time being. If the upstream decides to move it, we'll work out what to do then. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216114707.ga31...@enc.com.au
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Mon, Dec 16, 2013 at 10:47:07PM +1100, Craig Small wrote: On Tue, Dec 10, 2013 at 09:10:52AM +1100, Craig Small wrote: upstream what they are going to do? If they are going to keep pidof then the change is not required. If the projects plans is to Which I did. For the moment they have no plans moving pidof though they don't seem terribly fussed either way (that's my read of it anyhow). What I have done is used the --disable-pidof flag in procps configure step. This means procps does *not* have pidof and it can remain in sysvinit-tools for the time being. If the upstream decides to move it, we'll work out what to do then. Good to hear. Thanks for your diligence in following this up, Craig! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: procps with pidof is released
On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek vor...@debian.org wrote: On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote: Steve Langasek dixit: (For values of permanently that include we now have two implementations of sh in Essential, because no one has done the work to let us get rid of bash.) Maybe because the offered alternative sucks so much. You are totally, completely, 100% missing the point. We can't remove bash from Essential because packages are silently using /bin/bash without depending on bash, because they've been *told not to*. This is not about your hobby horse issue of whose /bin/sh is better, it's about the fact that once an interface makes its way into Essential, we have a very hard time removing it. The first step would be to change policy to no longer deprecate depending on bash if one uses ä!/bin/bash scripts. The second step would be a lintian warning if a package contains a #!/bin/bash script without depending on bash. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vsdhh-od...@swivel.zugschlus.de
Re: procps with pidof is released
On Sun, 2013-12-15 at 16:06 +0100, Marc Haber wrote: On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek vor...@debian.org wrote: On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote: Steve Langasek dixit: (For values of permanently that include we now have two implementations of sh in Essential, because no one has done the work to let us get rid of bash.) Maybe because the offered alternative sucks so much. You are totally, completely, 100% missing the point. We can't remove bash from Essential because packages are silently using /bin/bash without depending on bash, because they've been *told not to*. This is not about your hobby horse issue of whose /bin/sh is better, it's about the fact that once an interface makes its way into Essential, we have a very hard time removing it. The first step would be to change policy to no longer deprecate depending on bash if one uses ä!/bin/bash scripts. The second step would be a lintian warning if a package contains a #!/bin/bash script without depending on bash. What if I want to use bash features in a preinst script? The idea of making bash non-essential seems like pure busy-work; the vast majority of Debian systems will continue to have it installed and it will just result in a stream of RC bugs because of undeclared dependencies. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Re: procps with pidof is released
On Sun, Dec 15, 2013 at 07:07:54PM +, Ben Hutchings wrote: On Sun, 2013-12-15 at 16:06 +0100, Marc Haber wrote: On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek vor...@debian.org wrote: On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote: Steve Langasek dixit: (For values of permanently that include we now have two implementations of sh in Essential, because no one has done the work to let us get rid of bash.) Maybe because the offered alternative sucks so much. You are totally, completely, 100% missing the point. We can't remove bash from Essential because packages are silently using /bin/bash without depending on bash, because they've been *told not to*. This is not about your hobby horse issue of whose /bin/sh is better, it's about the fact that once an interface makes its way into Essential, we have a very hard time removing it. The first step would be to change policy to no longer deprecate depending on bash if one uses ä!/bin/bash scripts. The second step would be a lintian warning if a package contains a #!/bin/bash script without depending on bash. What if I want to use bash features in a preinst script? What if I want to write my preinst script in python? The idea of making bash non-essential seems like pure busy-work; the vast majority of Debian systems will continue to have it installed and it will just result in a stream of RC bugs because of undeclared dependencies. This is not /usr/share/common-licenses. The measure of whether something belongs in Essential is *not* how many packages reference it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: procps with pidof is released
On Sun, 2013-12-15 at 11:54 -0800, Steve Langasek wrote: On Sun, Dec 15, 2013 at 07:07:54PM +, Ben Hutchings wrote: On Sun, 2013-12-15 at 16:06 +0100, Marc Haber wrote: On Tue, 10 Dec 2013 13:22:27 -0800, Steve Langasek vor...@debian.org wrote: On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote: Steve Langasek dixit: (For values of permanently that include we now have two implementations of sh in Essential, because no one has done the work to let us get rid of bash.) Maybe because the offered alternative sucks so much. You are totally, completely, 100% missing the point. We can't remove bash from Essential because packages are silently using /bin/bash without depending on bash, because they've been *told not to*. This is not about your hobby horse issue of whose /bin/sh is better, it's about the fact that once an interface makes its way into Essential, we have a very hard time removing it. The first step would be to change policy to no longer deprecate depending on bash if one uses ä!/bin/bash scripts. The second step would be a lintian warning if a package contains a #!/bin/bash script without depending on bash. What if I want to use bash features in a preinst script? What if I want to write my preinst script in python? That has never been allowed, unlike use of bash. The idea of making bash non-essential seems like pure busy-work; the vast majority of Debian systems will continue to have it installed and it will just result in a stream of RC bugs because of undeclared dependencies. This is not /usr/share/common-licenses. The measure of whether something belongs in Essential is *not* how many packages reference it. Policy acknowledges that '[a]ny capability added to an essential package therefore creates an obligation to support that capability as part of the Essential set in perpetuity.' Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Re: procps with pidof is released
Steve Langasek dixit: (For values of permanently that include we now have two implementations of sh in Essential, because no one has done the work to let us get rid of bash.) Maybe because the offered alternative sucks so much. I’d happily split mksh into mksh and mksh-static, make the latter Essential, and help to get rid of dash and GNU bash in Essential. Or the other way round. Or just not split it, the savings on linux-any are not that big, and for kfreebsd-any I’ve got (longer-term) plans. SCNR, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312100900260.11...@herc.mirbsd.org
Re: procps with pidof is released
On Tue, Dec 10, 2013 at 09:02:21AM +, Thorsten Glaser wrote: Steve Langasek dixit: (For values of permanently that include we now have two implementations of sh in Essential, because no one has done the work to let us get rid of bash.) Maybe because the offered alternative sucks so much. You are totally, completely, 100% missing the point. We can't remove bash from Essential because packages are silently using /bin/bash without depending on bash, because they've been *told not to*. This is not about your hobby horse issue of whose /bin/sh is better, it's about the fact that once an interface makes its way into Essential, we have a very hard time removing it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Pkg-sysvinit-devel] procps with pidof is released
[sending this to both pkg-sysvinit-devel and debian-devel, instead of having two separate threads.] On Mon, Dec 09, 2013 at 01:49:37PM +1100, Craig Small wrote: On Sun, Dec 08, 2013 at 06:56:57PM +, Roger Leigh wrote: That sounds fine, I think. So on the sysvinit-utils side, we simply drop pidof? Yes, and the man page too. Will procps-base be guaranteed to be installed via upgrade? Now this I am unsure. It will be Essential but do new Essential packages automatically get installed? I imagine we'll have to also have a depends on procps-base = 3.3.9-1 to ensure pidof is available at all times during the upgrade? That depends on how Essential is handled. To ensure proper upgrade ordering, should the procps-base Breaks also be a Conflicts? (I mean, we want to avoid a window where any other packages/maintainer scripts need to use pidof but sysvinit-utils is upgraded but the new procps-base is not yet unpacked) I don't think so. I'm not an expert at how dpkg works but I thought if procps-base Breaks sysvinit X.Y.Z then if sysvinit X.Y.Z is there it won't get installed. Neither Conflicts nor Breaks; only Replaces. And sysvinit-utils needs to Pre-Depend on the new procps-base. Incidentally, AFAICS the pidof implementation in sysvinit appears to be built into the killall5 binary which we still ship and which you did not mention being part of procps-base. So in practice, this change doesn't appear to actually save us any code in sysvinit, which makes me wonder why we're making the change at all. You said that this was a result of discussions with sysvinit-tools upstream. Who is that upstream, and where did this discussion take place? Note that the upstream for our sysvinit package in Debian is http://savannah.nongnu.org/projects/sysvinit, which is not called sysvinit-tools, and the sysvinit-devel mailing list doesn't show any record of this discussion. AIUI, you've also proposed including the following list of binaries in procps-base: procps-base: pidof, ps, sysctl, pgrep, pkill Currently, the *only* one of these which is used as part of the essential set is pidof. Why would you put any of the rest of these in an essential package, given that you already have a binary package split between the Essential: yes procps-base and the Essential: no procps? Given the lack of discussion on sysvinit-devel and the unclear references to sysvinit-tools, I fear that we may be adopting a complicated transition for reasons that are actually completely unrelated to Debian's upstream. The procps mailing list thread[1] suggests this is about killing off sysvinit-tools in Red Hat. Well, that has nothing to do with us, and moving pidof around certainly doesn't kill off sysvinit-utils for us (there are still over a dozen other tools in that package in Debian). So why should we make this transition at all? AFAICS, the better solution here is to ignore the pidof binary from procps upstream and leave the existing packages alone. [1] http://www.freelists.org/post/procps/Adopting-pidof-from-sysvinittools,6 Just to double-check: the new pidof is completely compatible with the old? It's compatible in how it is called in Debian. There are some flags dropped but we never had them in the first place. It is a complete re-write by the sysvinit maintainers but they needed to move it out of that package; I assume its to do with upstart/systemd/whatever situation that all distributions are struggling/debating/arguing about. It looks like you're talking here not about the sysvinit maintainers, but the *Red Hat* sysvinit maintainers. Perhaps the rewrite of pidof is something that we want to pick up, but the rationale for including it in the procps package doesn't apply to Debian at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Mon, Dec 09, 2013 at 12:18:00PM -0800, Steve Langasek wrote: [...] AIUI, you've also proposed including the following list of binaries in procps-base: procps-base: pidof, ps, sysctl, pgrep, pkill Currently, the *only* one of these which is used as part of the essential set is pidof. Why would you put any of the rest of these in an essential package, given that you already have a binary package split between the Essential: yes procps-base and the Essential: no procps? [...] Discussed here: http://thread.gmane.org/gmane.linux.debian.devel.general/185723/focus=185725 -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209220309.ga16...@decadent.org.uk
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Mon, Dec 09, 2013 at 10:03:09PM +, Ben Hutchings wrote: Discussed here: http://thread.gmane.org/gmane.linux.debian.devel.general/185723/focus=185725 That's the leaving side, the arriving side is. http://www.freelists.org/post/procps/Adopting-pidof-from-sysvinittools Not sure what is happening with killall5. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209220656.ge23...@enc.com.au
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Mon, Dec 09, 2013 at 12:18:00PM -0800, Steve Langasek wrote: [sending this to both pkg-sysvinit-devel and debian-devel, instead of having two separate threads.] Good idea. It looks like you're talking here not about the sysvinit maintainers, but the *Red Hat* sysvinit maintainers. Perhaps the rewrite of pidof is something that we want to pick up, but the rationale for including it in the procps package doesn't apply to Debian at all. Right, can someone go and ask the sysvinit-utils or sysvinit-tools upstream what they are going to do? If they are going to keep pidof then the change is not required. If the projects plans is to retire/move it, then we will need to move it too. I'm not sure exactly who the exact upstream project it is. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209221052.gf23...@enc.com.au
Re: [Pkg-sysvinit-devel] procps with pidof is released
On Mon, Dec 09, 2013 at 10:03:09PM +, Ben Hutchings wrote: On Mon, Dec 09, 2013 at 12:18:00PM -0800, Steve Langasek wrote: [...] AIUI, you've also proposed including the following list of binaries in procps-base: procps-base: pidof, ps, sysctl, pgrep, pkill Currently, the *only* one of these which is used as part of the essential set is pidof. Why would you put any of the rest of these in an essential package, given that you already have a binary package split between the Essential: yes procps-base and the Essential: no procps? [...] Discussed here: http://thread.gmane.org/gmane.linux.debian.devel.general/185723/focus=185725 Well, you proposed it there, but it doesn't seem to have resulted in much actual discussion; I would expect more effort to be made to get wider input before adding these interfaces to Essential. The purpose of the Essential flag is to keep a minimal system working at all points during upgrades. It is not there to paper over bugs caused by maintainers being too lazy to properly declare their package dependencies. Yes, there probably are packages that are making buggy use of these commands today. But those are straightforward to find and fix using a lintian check, as Bastien proposed. There's no reason to saddle ourselves with more interfaces that must be supported permanently. (For values of permanently that include we now have two implementations of sh in Essential, because no one has done the work to let us get rid of bash.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
