Re: what to do with iputils (ping, etc)
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 directly use kernel functionality, then we get
> > > all the latest and greatest kernel networking features.
> >
> > What kind of features are we talking about here?
>
> 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.
Seems it is hard to stipulate this could be true forever. Should be resolve on
a per-case basis.
> The problem with making this change is really that it'll be so
> disruptive as to make it hard to consider the code as anything other
> than a fork. I'll revisit this claim, though. Maybe I can keep things
> from being quite so drastic. We'll see. I'm going to make an upload of
> iputils soon to fix a bunch of bugs, but after that, I'll see what I can
> do to please everybody and get the best of both worlds...
As we all know the upstream is a network shark and innovator, he needs that
stuff being tested/explored by developers/early-adopters/whatever and in
cases like that there is nothing wrong to use the netkit-* packages instead.
You might want to upload to experimental in case of disruptive changes made
and explain into README.Debian what have being changed if any and why, the
kernel headers needed to compile and so on. You may build-depend on certain
linux-kernel-headers package but depending on certain kernel image run time
could be a pita ;-/ ... so seems like a good candidate for experimental or
volatile ? archive to me.
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: