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 unrel
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
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 w
* 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
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
[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
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 th
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 bu
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 g
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 t
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 great
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 feature
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 s
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 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 li
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 s
[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 in
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 compl
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 p
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 n
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.
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, t
* 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 w
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 us
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
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
[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 k
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 wor
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 incl
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 incl
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 ker
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 def
32 matches
Mail list logo