[EMAIL PROTECTED] wrote:
How about naming the packages netkit-ping and iputils-ping,
respectively? Oh, wait, we have that already...
iputils-arping also has a more portable, alternative implementation
(cf. package arping). That leaves us with tracepath that indeed appears
to be Linux-only at the
On Oct 23, Nathanael Nerode [EMAIL PROTECTED] wrote:
Making one of the portable versions the default ping for Debian seems like
the
right thing to do.
Please explain why.
--
ciao,
Marco
signature.asc
Description: Digital signature
* Marco d'Itri ([EMAIL PROTECTED]) wrote:
On Oct 23, Nathanael Nerode [EMAIL PROTECTED] wrote:
Making one of the portable versions the default ping for Debian seems like
the
right thing to do.
Please explain why.
Consistancy. The alternatives system could be used if someone wants a
On Oct 23, Stephen Frost [EMAIL PROTECTED] wrote:
* Marco d'Itri ([EMAIL PROTECTED]) wrote:
On Oct 23, Nathanael Nerode [EMAIL PROTECTED] wrote:
Making one of the portable versions the default ping for Debian seems
like the
right thing to do.
Please explain why.
Consistancy.
On 23-Oct-05, 09:42 (CDT), Marco d'Itri [EMAIL PROTECTED] wrote:
On Oct 23, Stephen Frost [EMAIL PROTECTED] wrote:
* Marco d'Itri ([EMAIL PROTECTED]) wrote:
On Oct 23, Nathanael Nerode [EMAIL PROTECTED] wrote:
Making one of the portable versions the default ping for Debian seems
On Sun, Oct 23, 2005 at 11:33:47AM -0500, Steve Greenland wrote:
Making one of the portable versions the default ping for Debian seems
like the
right thing to do.
Please explain why.
Consistancy.
Losing important features to be consistent with unreleased toys does not
On Friday 21 October 2005 22.22, Noah Meyerhans wrote:
It depends on what you mean by up to date. If we're only including
glibc headers, then we can only use functionality that glibc supports.
If we bypass glibc and directly use kernel functionality, then we get
all the latest and greatest
On Sat, Oct 22, 2005 at 12:59:41PM +0200, Adrian von Bidder wrote:
It depends on what you mean by up to date. If we're only including
glibc headers, then we can only use functionality that glibc supports.
If we bypass glibc and directly use kernel functionality, then we get
all the latest
On Saturday 22 October 2005 17:29, Noah Meyerhans wrote:
On Sat, Oct 22, 2005 at 12:59:41PM +0200, Adrian von Bidder wrote:
It depends on what you mean by up to date. If we're only including
glibc headers, then we can only use functionality that glibc supports.
If we bypass glibc and
Hi,
Noah Meyerhans schrieb:
Hypothetical networking features that may be added to Linux in the
future. As I've said, I do not believe any existing features will need
to be removed in order to remove the linux specific bits of this
package.
Well, I think it would be acceptable to stop
Hi Noah,
On Fri, Oct 21, 2005 at 04:22:39PM -0400, Noah Meyerhans wrote:
It depends on what you mean by up to date. If we're only including
glibc headers, then we can only use functionality that glibc supports.
If we bypass glibc and directly use kernel functionality, then we get
all the
Before I go off and do something drastic like fork the iputils packages
(the packages that give us a handy little tool called 'ping') I'd like
to ask for advice from the wider community.
The iputils source package builds the iputils-{ping,tracepath,arping}
binary packages. Iputils-ping is the
On Oct 21, Noah Meyerhans [EMAIL PROTECTED] wrote:
and build process is a mess. The upstream developer is one of the
kernel network stack maintainers, and he wants the iputils package to
always work with the latest and greatest kernel functionality. As a
result, he includes lots of kernel
On Fri, Oct 21, 2005 at 08:51:43PM +0200, Marco d'Itri wrote:
and build process is a mess. The upstream developer is one of the
kernel network stack maintainers, and he wants the iputils package to
always work with the latest and greatest kernel functionality. As a
result, he includes
On Oct 21, Noah Meyerhans [EMAIL PROTECTED] wrote:
and build process is a mess. The upstream developer is one of the
kernel network stack maintainers, and he wants the iputils package to
always work with the latest and greatest kernel functionality. As a
result, he includes lots of
On 10/21/05, Marco d'Itri [EMAIL PROTECTED] wrote:
I could not care less about hurd or kFreeBSD, sorry.
But I care a lot about having a working and up to date iputils package
for my Linux systems, and I do not want Debian to fork it unless there
Is a portable version required to be not working
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Oct 21, Noah Meyerhans [EMAIL PROTECTED] wrote:
and build process is a mess. The upstream developer is one of the
kernel network stack maintainers, and he wants the iputils package to
always work with the latest and greatest kernel
On Fri, Oct 21, 2005 at 12:54:53PM -0700, Thomas Bushnell BSG wrote:
Folding the headers into the package does not advance this goal, it
retards it.
The inclusion of the kernel headers into the package was an explicitly
temporary fix for version 3:20020927-2:
* Build system cleanup. Stop
On Oct 21, Olaf van der Spek [EMAIL PROTECTED] wrote:
I could not care less about hurd or kFreeBSD, sorry.
But I care a lot about having a working and up to date iputils package
for my Linux systems, and I do not want Debian to fork it unless there
Is a portable version required to be not
On Fri, Oct 21, 2005 at 10:13:30PM +0200, Marco d'Itri wrote:
Is a portable version required to be not working and not up to date?
If the upstream maintainer is not interested in it, yes.
It depends on what you mean by up to date. If we're only including
glibc headers, then we can only use
* Noah Meyerhans ([EMAIL PROTECTED]) wrote:
On Fri, Oct 21, 2005 at 10:13:30PM +0200, Marco d'Itri wrote:
Is a portable version required to be not working and not up to date?
If the upstream maintainer is not interested in it, yes.
It depends on what you mean by up to date. If we're only
On Oct 21, Noah Meyerhans [EMAIL PROTECTED] wrote:
It depends on what you mean by up to date. If we're only including
glibc headers, then we can only use functionality that glibc supports.
Which I would consider a big problem.
If we bypass glibc and directly use kernel functionality, then we
On Fri, Oct 21, 2005 at 10:54:58PM +0200, Marco d'Itri wrote:
So yes, in some sense, a portable ping may be out of date. This is
exactly why the upstream author didn't accept my patches to remove the
dependency on kernel headers. He cares more about the package being up
to date. Our
On Fri, Oct 21, 2005 at 09:43:47PM +0200, Marco d'Itri wrote:
I could not care less about hurd or kFreeBSD, sorry.
Of course: Debian must be optimized for your case, and your case only.
But I care a lot about having a working and up to date iputils package
for my Linux systems, and I do not
On Fri, Oct 21, 2005 at 10:54:58PM +0200, Marco d'Itri wrote:
On Oct 21, Noah Meyerhans [EMAIL PROTECTED] wrote:
It depends on what you mean by up to date. If we're only including
glibc headers, then we can only use functionality that glibc supports.
Which I would consider a big problem.
On Oct 21, Steve Langasek [EMAIL PROTECTED] wrote:
Your message would seem less confrontational if you would deign to explain
*why* Linux-specific kernel features are important in a ping implementation.
Because features like ping -M are of invaluable help when investigating
issues more complex
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Oct 21, Steve Langasek [EMAIL PROTECTED] wrote:
Your message would seem less confrontational if you would deign to explain
*why* Linux-specific kernel features are important in a ping implementation.
Because features like ping -M are of invaluable
On Fri, Oct 21, 2005 at 04:41:48PM -0400, Stephen Frost wrote:
It seems like the 'sensible' thing to do might be to provide both.
Typically I would think the standard 'ping' would be, well, pretty
standard, and would work across multiple kernels/OSes/etc. We could
also have an 'lping' or some
On Fri, Oct 21, 2005 at 11:44:45PM +0200, Marco d'Itri wrote:
On Oct 21, Steve Langasek [EMAIL PROTECTED] wrote:
Your message would seem less confrontational if you would deign to explain
*why* Linux-specific kernel features are important in a ping implementation.
Because features like ping
On Oct 21, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
How on earth does supporting that feature require incompatibility with
other systems?
It does not, but the iputils maintainer is hinting that this is the
package status.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Fri, Oct 21, 2005 at 04:41:48PM -0400, Stephen Frost wrote:
It seems like the 'sensible' thing to do might be to provide both.
Typically I would think the standard 'ping' would be, well, pretty
standard, and would work across multiple kernels/OSes/etc. We could
also have an 'lping' or some
On Fri, Oct 21, 2005 at 11:52:02PM +0200, Marco d'Itri wrote:
How on earth does supporting that feature require incompatibility with
other systems?
It does not, but the iputils maintainer is hinting that this is the
package status.
I never said anything about the PMTU discovery features.
32 matches
Mail list logo
