Rename netkitbase and netkittelnet

Rename netkitbase and netkittelnet according to naming policy.
Updates package/Config.in and busybox.mk accordingly.

Signed-off-by: Arnaud Aujon <arnaud.aujon@gmail.com>
---
 package/Config.in                                    |  4 ++--
 package/busybox/busybox.mk                           | 12 ++++++------
 package/{netkitbase => netkit-base}/Config.in        |  6 +++---
 .../netkit-base-gcc4.patch}                          |  0
 .../netkit-base-remove-bcopy.patch}                  |  0
 .../netkitbase.mk => netkit-base/netkit-base.mk}     | 20 ++++++++++----------
 package/{netkittelnet => netkit-telnet}/Config.in    |  8 ++++----
 .../netkit-telnet-bcopy.patch}                       |  0
 .../netkit-telnet.mk}                                | 18 +++++++++---------
 .../netkit-telnet.patch}                             |  0
 10 files changed, 34 insertions(+), 34 deletions(-)
 rename package/{netkitbase => netkit-base}/Config.in (70%)
 rename package/{netkitbase/netkitbase-gcc4.patch => netkit-base/netkit-base-gcc4.patch} (100%)
 rename package/{netkitbase/netkitbase-remove-bcopy.patch => netkit-base/netkit-base-remove-bcopy.patch} (100%)
 rename package/{netkitbase/netkitbase.mk => netkit-base/netkit-base.mk} (60%)
 rename package/{netkittelnet => netkit-telnet}/Config.in (61%)
 rename package/{netkittelnet/netkittelnet-bcopy.patch => netkit-telnet/netkit-telnet-bcopy.patch} (100%)
 rename package/{netkittelnet/netkittelnet.mk => netkit-telnet/netkit-telnet.mk} (69%)
 rename package/{netkittelnet/netkittelnet.patch => netkit-telnet/netkit-telnet.patch} (100%)

Dear Arnaud Aujon,

On Thu, 24 Oct 2013 10:55:17 +0200, Arnaud Aujon wrote:
> Rename netkitbase and netkittelnet according to naming policy.
> Updates package/Config.in and busybox.mk accordingly.
> 
> Signed-off-by: Arnaud Aujon <arnaud.aujon@gmail.com>

Both of these packages have been marked deprecated since almost a year
(November 2013). See 442765fe3d8767956eb26d4bcbaa62ce1e1782ca and
5a457ff6cc3129af97f2fdcaa5f88bd5ff02b500.

So many it's simpler better to remove them completely?

Because what your patch is missing is that it's renaming the Config.in
options for those two packages, but it's not adding the necessary
compatibility informations in Config.in.legacy. And I don't think it's
really worth doing that for packages that have been deprecated a year
ago. What do you think?

Best regards,

Thomas

Hi,

2013/10/24 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Both of these packages have been marked deprecated since almost a year
> (November 2013). See 442765fe3d8767956eb26d4bcbaa62ce1e1782ca and
> 5a457ff6cc3129af97f2fdcaa5f88bd5ff02b500.
>
> So many it's simpler better to remove them completely?
>
> Because what your patch is missing is that it's renaming the Config.in
> options for those two packages, but it's not adding the necessary
> compatibility informations in Config.in.legacy. And I don't think it's
> really worth doing that for packages that have been deprecated a year
> ago. What do you think?
>

I didn't notice that. I guess after 1 year the best thing would be to
remove it completely.
Moreover it looks like there is some security issues (
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0911)
that haven't been fixed upstream (last version is from 2000 I think)

Hi,

2013/10/24 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
>> Both of these packages have been marked deprecated since almost a year
>> (November 2013). See 442765fe3d8767956eb26d4bcbaa62ce1e1782ca and
>> 5a457ff6cc3129af97f2fdcaa5f88bd5ff02b500.
>>
>> So many it's simpler better to remove them completely?
>
>
Now that 2013.11 is out, what about removing these packages ?
Peter, what do you think ?

Dear arnaud aujon,

On Tue, 3 Dec 2013 09:47:08 +0100, arnaud aujon wrote:
> Hi,
> 
> 2013/10/24 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >
> >> Both of these packages have been marked deprecated since almost a year
> >> (November 2013). See 442765fe3d8767956eb26d4bcbaa62ce1e1782ca and
> >> 5a457ff6cc3129af97f2fdcaa5f88bd5ff02b500.
> >>
> >> So many it's simpler better to remove them completely?
> >
> >
> Now that 2013.11 is out, what about removing these packages ?
> Peter, what do you think ?

Both of these packages are marked as deprecated since 2012.11, so I
think we can safely remove them. In the Config.in.legacy entries that
will replace the two Config.in options of those packages, it would be
important to mention what are the replacement for those packages.

Best regards,

Thomas

Ok, so netkitbase provides 2 binaries : inetd which can be replaced by
xinetd and ping that is provided by busybox (is there another package
providing it ?)
For netkittelnet, again busybox provides a telnet client.
So Config.in.legacy should be updated by something like that :

config BR2_PACKAGE_NETKITBASE
    bool "netkitbase has been removed"
    select BR2_LEGACY
    help
      The 'netkitbase' package has been removed, since it
      has been deprecated since 2012.11. This package provided  'inetd'
which
      is replaced by 'xinet' and 'ping' which is replaced by 'busybox' or
'fping'.

config BR2_PACKAGE_NETKITTELNET
    bool "netkittelnet has been removed"
    select BR2_LEGACY
    help
      The 'netkittelnet' package has been removed, since it
      has been deprecated since 2012.11. 'busybox' provides a telnet client
and
      should be used instead.

But should we automatically select a replacement or let the user decide
what to do ?




2013/12/3 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Dear arnaud aujon,
>
> On Tue, 3 Dec 2013 09:47:08 +0100, arnaud aujon wrote:
> > Hi,
> >
> > 2013/10/24 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > >
> > >> Both of these packages have been marked deprecated since almost a year
> > >> (November 2013). See 442765fe3d8767956eb26d4bcbaa62ce1e1782ca and
> > >> 5a457ff6cc3129af97f2fdcaa5f88bd5ff02b500.
> > >>
> > >> So many it's simpler better to remove them completely?
> > >
> > >
> > Now that 2013.11 is out, what about removing these packages ?
> > Peter, what do you think ?
>
> Both of these packages are marked as deprecated since 2012.11, so I
> think we can safely remove them. In the Config.in.legacy entries that
> will replace the two Config.in options of those packages, it would be
> important to mention what are the replacement for those packages.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>

Dear arnaud aujon,

On Fri, 13 Dec 2013 18:51:45 +0100, arnaud aujon wrote:
> Ok, so netkitbase provides 2 binaries : inetd which can be replaced by
> xinetd and ping that is provided by busybox (is there another package
> providing it ?)

There is iputils, but we don't have a package for it in Buildroot (I
have one in a private branch, just haven't had the time to clean it up
to upstream it). It provides, amongst others, the full-featured ping
implementation.

> For netkittelnet, again busybox provides a telnet client.
> So Config.in.legacy should be updated by something like that :
> 
> config BR2_PACKAGE_NETKITBASE
>     bool "netkitbase has been removed"
>     select BR2_LEGACY
>     help
>       The 'netkitbase' package has been removed, since it
>       has been deprecated since 2012.11. This package provided  'inetd'
> which
>       is replaced by 'xinet' and 'ping' which is replaced by 'busybox' or
> 'fping'.
> 
> config BR2_PACKAGE_NETKITTELNET
>     bool "netkittelnet has been removed"
>     select BR2_LEGACY
>     help
>       The 'netkittelnet' package has been removed, since it
>       has been deprecated since 2012.11. 'busybox' provides a telnet client
> and
>       should be used instead.
> 
> But should we automatically select a replacement or let the user decide
> what to do ?

Normally, we select things automatically, when there is a direct match.
In this case, I believe there isn't really a direct complete match, so
I would personally suggest to not select something automatically.

Best regards,

Thomas