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: procps trying to overwrite /bin/kill
On Wed, Oct 06, 1999 at 02:24:35AM -0400, Colin Walters wrote: Package: procps Version: 1:2.0.3-3 Preparing to replace procps 1:2.0.3-3 (using .../procps_1%3a2.0.3-4_i386.deb) .. . Unpacking replacement procps ... dpkg: error processing /var/cache/apt/archives/procps_1%3a2.0.3-4_i386.deb (--un pack): trying to overwrite `/bin/kill', which is also in package bsdutils dpkg-deb: subprocess paste killed by signal (Broken pipe) This seems to be seriously broken. No, news bsdutils package is without kill. Mirek
Re: procps trying to overwrite /bin/kill
Mirek Kwasniak [EMAIL PROTECTED] writes: On Wed, Oct 06, 1999 at 02:24:35AM -0400, Colin Walters wrote: Package: procps Version: 1:2.0.3-3 Preparing to replace procps 1:2.0.3-3 (using .../procps_1%3a2.0.3-4_i386.deb) .. . Unpacking replacement procps ... dpkg: error processing /var/cache/apt/archives/procps_1%3a2.0.3-4_i386.deb (--un pack): trying to overwrite `/bin/kill', which is also in package bsdutils dpkg-deb: subprocess paste killed by signal (Broken pipe) This seems to be seriously broken. No, news bsdutils package is without kill. Then there should be a proper conflicts or replaces header in the procps package. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: procps trying to overwrite /bin/kill
On Wed, Oct 06, 1999 at 09:44:46AM +0200, Mirek Kwasniak wrote: No, news bsdutils package is without kill. Oh, wee, another portable program bites the dust. Is the kill in procps linux specific, eg, does it make use of the proc filesystem? This won't work in the Hurd, so the Hurd would be without a kill. But then, we haven't ported util-linux yet (we can still use their kill even if linux ports don't). Maybe we should just fork out our own version of kill, as this seems to be the last fashion here. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: procps
-BEGIN PGP SIGNED MESSAGE- On Thu, 8 Jan 1998, Ulf Jaenicke-Roessler wrote: where should 'ps' reside, according to the standard? In the latest version it moved from /bin/ps to /usr/bin/ps. According to the maintainer, it will be moved back to /bin. This is bug #16705. Thanks. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLTXryqK7IlOjMLFAQEsfwQAg/Q9yeZTsMwgZoB1mtGyA0sVVC/9ez5A fUtBFy/jMZRIlYznZHCGS12q23zUvAJCa6vkXNYMjKMcbiCI6p9Pm/nXZjxGUNvw 4fLt+n8gXkpsAw9XbaHo4+j9n7od9mpixQOjzR18ht2HNKXkkpMaX7NJT8BEy48B FVYC1E1PBh8= =6PS5 -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
BTW, Does anyone know where killall went? procps_1.2.2-1 doesn't seem to include it. killall is used in quite a lot of scripts, which are now starting to break. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
[EMAIL PROTECTED] (Ulf Jaenicke-Roessler) writes: where should 'ps' reside, according to the standard? In the latest version it moved from /bin/ps to /usr/bin/ps. I noticed this too, and filed a bug. The maintainer says it will return to /bin in the next release. Martin. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
On Thu, 8 Jan 1998, Bart Schuller wrote: BTW, Does anyone know where killall went? procps_1.2.2-1 doesn't seem to include it. killall is used in quite a lot of scripts, which are now starting to break. Yes, it got broken out upstream into a seperate psmisc package. Which is now stuck in incoming. You can find an incoming mirror at ftp://ftp1.us.debian.org/pub/debian/Incoming -- Scott K. Ellis [EMAIL PROTECTED] http://www.gate.net/~storm/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
On Jan 8, Scott Ellis wrote On Thu, 8 Jan 1998, Bart Schuller wrote: Does anyone know where killall went? procps_1.2.2-1 doesn't seem to include it. killall is used in quite a lot of scripts, which are now starting to break. Yes, it got broken out upstream into a seperate psmisc package. Which is now stuck in incoming. You can find an incoming mirror at ftp://ftp1.us.debian.org/pub/debian/Incoming Thanks. I mut say I find the policy with respect to split or renamed packages getting stuck in Incoming suboptimal. First e2fsprogsg, now killall. It is a bit too easy to end up with a broken system, something which the policy for new packages is supposed to prevent. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
On Thu, Jan 08, 1998 at 03:10:19PM +0100, Bart Schuller wrote: Does anyone know where killall went? procps_1.2.2-1 doesn't seem to include it. killall is used in quite a lot of scripts, which are now starting to break. Yes, it got broken out upstream into a seperate psmisc package. Which is now stuck in incoming. You can find an incoming mirror at ftp://ftp1.us.debian.org/pub/debian/Incoming Thanks. I mut say I find the policy with respect to split or renamed packages getting stuck in Incoming suboptimal. First e2fsprogsg, now killall. Seconded. Please file a bugreport against ftp.debian.org so Guy remembers this. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / Whenever you meet yourself you're in a time loop / / http://home.pages.de/~joey/ or in front of a mirror / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
On Thu, Jan 08, 1998 at 03:13:05PM +0100, Martin Schulze wrote: On Thu, Jan 08, 1998 at 03:10:19PM +0100, Bart Schuller wrote: I mut say I find the policy with respect to split or renamed packages getting stuck in Incoming suboptimal. First e2fsprogsg, now killall. Please file a bugreport against ftp.debian.org so Guy remembers this. Note that this is probably already covered: #4378: Dependencies should be checked automatically #9857: ftp 'dinstall' needs to check dependancies Ray -- UNFAIR Term applied to advantages enjoyed by other people which we tried to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, UNDERHAND and JUST LUCKY I GUESS. - The Hipcrime Vocab by Chad C. Mulligan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
On Jan 8, [EMAIL PROTECTED] wrote Please file a bugreport against ftp.debian.org so Guy remembers this. Note that this is probably already covered: #4378: Dependencies should be checked automatically #9857: ftp 'dinstall' needs to check dependancies Now you're really scaring me: out of curiosity, I browsed the first bug report, which contains this beauty of a message: Hi! I'm on vacation for one month, so I'm not reading any email. I'll be back on July 14, and I'll respond to all my email by July 16. You will only receive this email once. Guy To me this illustrates the severity of the situation. (Note, btw, that this is nothing personal against the current ftp site maintainer, it's the whole procedure I have a problem with). -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
