Skip to contentSkip to conversation

inetutils: new package

PATCH New Karoly Kasza 4 participants 15 messages Oct 29, 2014 – Nov 10, 2014

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 inetutils: new package

GNU Inetutils is a collection of common network programs. Clients included:
dnsdomainname, ftp, hostname, ifconfig, logger, ping, ping6, rcp, rexec, rlogin, rsh, talk, telnet, tftp, traceroute, whois Servers included:
ftpd, inetd, rexecd, rlogind, rshd, syslogd, talkd, telnetd, tftpd, uucpd

---
 package/Config.in                                  |    3 +
 package/inetutils/Config.in                        |   78 ++++++++++++++++++++
 .../inetutils/inetutils-01-PATH_PROCNET_DEV.patch  |   21 ++++++
 package/inetutils/inetutils.hash                   |    2 +
 package/inetutils/inetutils.mk                     |   73 ++++++++++++++++++
 5 files changed, 177 insertions(+)
 create mode 100644 package/inetutils/Config.in
 create mode 100644 package/inetutils/inetutils-01-PATH_PROCNET_DEV.patch
 create mode 100644 package/inetutils/inetutils.hash
 create mode 100644 package/inetutils/inetutils.mk
package/Config.in +3 -0
index 5de4df9..fa894da 100644
@@ -1016,6 +1016,9 @@ endif
 	source "package/igh-ethercat/Config.in"
 	source "package/igmpproxy/Config.in"
 	source "package/inadyn/Config.in"
+if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
+	source "package/inetutils/Config.in"
+endif
 	source "package/iperf/Config.in"
 	source "package/iproute2/Config.in"
 	source "package/ipsec-tools/Config.in"
package/inetutils/Config.in new file +78 -0

78 lines not on this page · raw message

package/inetutils/inetutils-01-PATH_PROCNET_DEV.patch new file +21 -0
new file mode 100644
index 0000000..98ae46c
@@ -0,0 +1,21 @@
+Fix missing #define
+
+Patch from:
+http://repository.timesys.com/buildsources/i/inetutils/inetutils-1.9.1/inetutils-1.9.1-PATH_PROCNET_DEV.patch
+
+Signed-off-by: Karoly Kasza <[email protected]>
+
+diff -Naur inetutils-1.9.1.orig/ifconfig/system/linux.c inetutils-1.9.1/ifconfig/system/linux.c
+--- inetutils-1.9.1.orig/ifconfig/system/linux.c	2012-01-09 11:45:35.000000000 -0500
++++ inetutils-1.9.1/ifconfig/system/linux.c	2012-01-09 11:46:13.000000000 -0500
+@@ -49,6 +49,10 @@
+ #include "../ifconfig.h"
+ 
+ 
++#ifndef PATH_PROCNET_DEV
++  #define PATH_PROCNET_DEV "/proc/net/dev"
++#endif
++
+ /* ARPHRD stuff.  */
+ 
+ static void
package/inetutils/inetutils.hash new file +2 -0
new file mode 100644
index 0000000..6c1205e
@@ -0,0 +1,2 @@
+# calculated after checking PGP signature (signed by ams at gnu.org)
+sha256	e3783372540772bbadd6aa2c90f8a75511db4e7d40bbfa37ffdb1bc7a9697f3e	inetutils-1.9.2.tar.xz
package/inetutils/inetutils.mk new file +73 -0

73 lines not on this page · raw message

Signature · 1 line
1.7.10.4
#1 lore raw

PATCH 1/1 inetutils: new package

----- Mail original -----

Quoted 4 lines

GNU Inetutils is a collection of common network programs. Clients included:
dnsdomainname, ftp, hostname, ifconfig, logger, ping, ping6, rcp, rexec, rlogin, rsh, talk, telnet, tftp, traceroute, whois

ifconfig and hostname are already in the package "net-tools" are they related ? is that a different provider for the package ?

Quoted 252 lines

Servers included:
ftpd, inetd, rexecd, rlogind, rshd, syslogd, talkd, telnetd, tftpd, uucpd

---
 package/Config.in                                  |    3 +
 package/inetutils/Config.in                        |   78
 ++++++++++++++++++++
 .../inetutils/inetutils-01-PATH_PROCNET_DEV.patch  |   21 ++++++
 package/inetutils/inetutils.hash                   |    2 +
 package/inetutils/inetutils.mk                     |   73
 ++++++++++++++++++
 5 files changed, 177 insertions(+)
 create mode 100644 package/inetutils/Config.in
 create mode 100644
 package/inetutils/inetutils-01-PATH_PROCNET_DEV.patch
 create mode 100644 package/inetutils/inetutils.hash
 create mode 100644 package/inetutils/inetutils.mk
package/Config.in +3 -0
index 5de4df9..fa894da 100644
@@ -1016,6 +1016,9 @@ endif
 	source "package/igh-ethercat/Config.in"
 	source "package/igmpproxy/Config.in"
 	source "package/inadyn/Config.in"
+if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
+	source "package/inetutils/Config.in"
+endif
 	source "package/iperf/Config.in"
 	source "package/iproute2/Config.in"
 	source "package/ipsec-tools/Config.in"
package/inetutils/Config.in new file +10 -0
new file mode 100644
index 0000000..28a34e7
@@ -0,0 +1,78 @@
+config BR2_PACKAGE_INETUTILS
+	bool "inetutils"
+	depends on BR2_USE_WCHAR
+	help
+	  GNU Inetutils is a collection of common network programs.
+	  Clients included:
+	  dnsdomainname, ftp, hostname, ifconfig, logger, ping, ping6, rcp,
+	  rexec, rlogin, rsh, talk, telnet, tftp, traceroute, whois
+	  Servers included:
+	  ftpd, inetd, rexecd, rlogind, rshd, syslogd, talkd, telnetd,

tftpd,

package/inetutils/Config.in new file +17 -0
+	  uucpd
+
+if BR2_PACKAGE_INETUTILS
+
+config BR2_PACKAGE_INETUTILS_CLIENTS_CORE
+	bool "core clients"
+	default y
+	help
+	  Includes:
+	  ftp, telnet, tftp
+
+config BR2_PACKAGE_INETUTILS_CLIENTS_UTIL
+	bool "utility clients"
+	depends on BR2_INET_IPV6
+	help
+	  Includes:
+	  dnsdomainname, hostname, ifconfig, logger, ping, ping6,

traceroute, whois

package/inetutils/Config.in new file +51 -0
+
+comment "utility clients needs a toolchain w/ IPv6"
+	depends on !BR2_INET_IPV6
+
+config BR2_PACKAGE_INETUTILS_CLIENTS_LEGACY
+	bool "legacy clients"
+	depends on BR2_INET_IPV6
+	depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC
+	select BR2_PACKAGE_NCURSES
+	help
+	  Includes:
+	  rcp, rexec, rlogin, rsh, talk
+
+comment "legacy clients needs a toolchain w/ IPv6, RPC"
+	depends on !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_NATIVE_RPC
+
+config BR2_PACKAGE_INETUTILS_SERVERS_CORE
+	bool "core servers"
+	depends on BR2_INET_IPV6
+	help
+	  Includes:
+	  ftpd, inetd, telnetd, tftpd
+
+comment "core servers needs a toolchain w/ IPv6"
+	depends on !BR2_INET_IPV6
+
+config BR2_PACKAGE_INETUTILS_SERVERS_UTIL
+	bool "utility servers"
+	depends on BR2_INET_IPV6
+	help
+	  Includes:
+	  syslogd
+
+comment "utility servers needs a toolchain w/ IPv6"
+	depends on !BR2_INET_IPV6
+
+config BR2_PACKAGE_INETUTILS_SERVERS_LEGACY
+	bool "legacy servers"
+	depends on BR2_INET_IPV6
+	depends on BR2_TOOLCHAIN_HAS_NATIVE_RPC
+	help
+	  Includes:
+	  rexecd, rlogind, rshd, talkd, uucpd
+
+comment "legacy servers needs a toolchain w/ IPv6, RPC"
+	depends on !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_NATIVE_RPC
+
+endif
+
+comment "inetutils needs a toolchain w/ wchar"
+	depends on !BR2_USE_WCHAR
package/inetutils/inetutils-01-PATH_PROCNET_DEV.patch new file +8 -0
new file mode 100644
index 0000000..98ae46c
@@ -0,0 +1,21 @@
+Fix missing #define
+
+Patch from:
+http://repository.timesys.com/buildsources/i/inetutils/inetutils-1.9.1/inetutils-1.9.1-PATH_PROCNET_DEV.patch
+
+Signed-off-by: Karoly Kasza <[email protected]>
+
+diff -Naur inetutils-1.9.1.orig/ifconfig/system/linux.c

inetutils-1.9.1/ifconfig/system/linux.c
+--- inetutils-1.9.1.orig/ifconfig/system/linux.c 2012-01-09
11:45:35.000000000 -0500
++++ inetutils-1.9.1/ifconfig/system/linux.c 2012-01-09
11:46:13.000000000 -0500
+@@ -49,6 +49,10 @@
+ #include "../ifconfig.h"

package/inetutils/inetutils-01-PATH_PROCNET_DEV.patch new file +9 -0
+
+
++#ifndef PATH_PROCNET_DEV
++  #define PATH_PROCNET_DEV "/proc/net/dev"
++#endif
++
+ /* ARPHRD stuff.  */
+
+ static void
package/inetutils/inetutils.hash new file +2 -0
new file mode 100644
index 0000000..6c1205e
@@ -0,0 +1,2 @@
+# calculated after checking PGP signature (signed by ams at gnu.org)
+sha256
	e3783372540772bbadd6aa2c90f8a75511db4e7d40bbfa37ffdb1bc7a9697f3e
	inetutils-1.9.2.tar.xz
package/inetutils/inetutils.mk new file +68 -0
new file mode 100644
index 0000000..8ed3365
@@ -0,0 +1,73 @@
+################################################################################
+#
+# inetutils
+#
+################################################################################
+
+INETUTILS_VERSION = 1.9.2
+INETUTILS_SITE = $(BR2_GNU_MIRROR)/inetutils
+INETUTILS_SOURCE = inetutils-$(INETUTILS_VERSION).tar.xz
+INETUTILS_LICENSE = GPLv3
+INETUTILS_LICENSE_FILES = COPYING
+
+# Disable everything by default and enable if selected
+INETUTILS_CONF_OPTS += --disable-clients --disable-servers
+
+ifeq ($(BR2_PACKAGE_INETUTILS_CLIENTS_CORE),y)
+INETUTILS_CONF_OPTS += --enable-ftp \
+		       --enable-telnet \
+		       --enable-tftp
+endif
+
+ifeq ($(BR2_PACKAGE_INETUTILS_CLIENTS_UTIL),y)
+INETUTILS_CONF_OPTS += --enable-dnsdomainname \
+		       --enable-hostname \
+		       --enable-ifconfig \
+		       --enable-logger \
+		       --enable-ping \
+		       --enable-ping6 \
+		       --enable-traceroute \
+		       --enable-whois
+endif
+
+ifeq ($(BR2_PACKAGE_INETUTILS_CLIENTS_LEGACY),y)
+# For talk client
+INETUTILS_DEPENDENCIES += ncurses
+INETUTILS_CONF_OPTS += --enable-rcp \
+		       --enable-rexec \
+		       --enable-rlogin \
+		       --enable-rsh \
+		       --enable-talk
+endif
+
+ifeq ($(BR2_PACKAGE_INETUTILS_SERVERS_CORE),y)
+INETUTILS_CONF_OPTS += --enable-ftpd \
+		       --enable-inetd \
+		       --enable-telnetd \
+		       --enable-tftpd
+endif
+
+ifeq ($(BR2_PACKAGE_INETUTILS_SERVERS_UTIL),y)
+INETUTILS_CONF_OPTS += --enable-syslogd
+endif
+
+ifeq ($(BR2_PACKAGE_INETUTILS_SERVERS_LEGACY),y)
+INETUTILS_CONF_OPTS += --enable-rexecd \
+		       --enable-rlogind \
+		       --enable-rshd \
+		       --enable-talkd \
+		       --enable-uucpd
+endif
+
+# Only possible with "core clients"
+ifeq ($(BR2_INET_IPV6),)
+INETUTILS_CONF_OPTS += --disable-ipv6
+endif
+
+# If both inetutils and busybox are selected, make certain inetutils
+# wins the fight over who gets to have their utils actually

installed.

package/inetutils/inetutils.mk new file +5 -1
+ifeq ($(BR2_PACKAGE_BUSYBOX),y)
+INETUTILS_DEPENDENCIES += busybox
+endif
+
+$(eval $(autotools-package))
--

1.7.10.4

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

#2 lore raw

PATCH 1/1 inetutils: new package

Hello Jeremy,

indeed there are many programs in inetutils, that are also provided by other packages.
I decided to split the package into 6 separate parts, so "one does not simply" need to compile/carry everything :)
Inetutils is the GNU implementation of these, the user can choose whatever fits best for him/her.

My primary reason for adding Inetutils is telnet (and telnetd), which are not provided by anything else, if
the user chooses not to use Busybox.

Best regards,
Karoly

Quoted 12 lines · Jeremy Rosen

----- Mail original -----

Quoted 4 lines

GNU Inetutils is a collection of common network programs. Clients included:
dnsdomainname, ftp, hostname, ifconfig, logger, ping, ping6, rcp, rexec, rlogin, rsh, talk, telnet, tftp, traceroute, whois

ifconfig and hostname are already in the package "net-tools" are they related ? is that a different provider for the package ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141030/0c1bb943/attachment.html>

#3 lore raw

PATCH 1/1 inetutils: new package

Hi K?roly,

Quoted 6 lines · K?roly Kasza

indeed there are many programs in inetutils, that are also provided by other packages.
I decided to split the package into 6 separate parts, so "one does not simply" need to compile/carry everything :)
Inetutils is the GNU implementation of these, the user can choose whatever fits best for him/her.

But you should consider what happens when one selects both versions. Which one should "win"? We can't leave it to chance.

baruch

Quoted 15 lines

My primary reason for adding Inetutils is telnet (and telnetd), which are not provided by anything else, if
the user chooses not to use Busybox.

Quoted 8 lines · Jeremy Rosen

----- Mail original -----

Quoted 4 lines

GNU Inetutils is a collection of common network programs. Clients included:
dnsdomainname, ftp, hostname, ifconfig, logger, ping, ping6, rcp, rexec, rlogin, rsh, talk, telnet, tftp, traceroute, whois

ifconfig and hostname are already in the package "net-tools" are they related ? is that a different provider for the package ?

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#4 lore raw

PATCH 1/1 inetutils: new package

Hi Baruch,

Buildroot handles these "race conditions" with the <package>_DEPENDENCIES variables.
I added Busybox as one (if selected), so Inetutils will always win over Busybox (that is probably
unnecessary btw, Busybox should always be built before other packages - but I'm not sure in cases, where
Busybox is built, but not the default init system nor shell). The other packages who provide anything related to inetutils are not yet added, but of course they can be added
to act as dependencies.
The question is, why do anybody want to compile and use different implementations of one program? I mean what
could be the use case?

Best regards,
Karoly

Quoted 39 lines · Baruch Siach

Hi K?roly,

Quoted 5 lines · K?roly Kasza

indeed there are many programs in inetutils, that are also provided by other packages.
I decided to split the package into 6 separate parts, so "one does not simply" need to compile/carry everything :)
Inetutils is the GNU implementation of these, the user can choose

whatever

Quoted 1 line

fits best for him/her.

But you should consider what happens when one selects both versions. Which one
should "win"? We can't leave it to chance.

baruch

Quoted 4 lines

My primary reason for adding Inetutils is telnet (and telnetd), which are not provided by anything else, if
the user chooses not to use Busybox.

Quoted 11 lines
Quoted 8 lines · Jeremy Rosen

----- Mail original -----

Quoted 4 lines

GNU Inetutils is a collection of common network programs. Clients included:
dnsdomainname, ftp, hostname, ifconfig, logger, ping, ping6, rcp, rexec, rlogin, rsh, talk, telnet, tftp, traceroute, whois

ifconfig and hostname are already in the package "net-tools" are they related ? is that a different provider for the package ?

--
http://baruch.siach.name/blog/ ~. .~ Tk Open
Systems =}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Signature · 5 lines
?dv,
KK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141030/b5d30d27/attachment.html>
#5 lore raw

PATCH 1/1 inetutils: new package

Hi K?roly,

Quoted 5 lines · K?roly Kasza

Buildroot handles these "race conditions" with the <package>_DEPENDENCIES variables.
I added Busybox as one (if selected), so Inetutils will always win over Busybox (that is probably
unnecessary btw, Busybox should always be built before other packages - but

Quoted 8 lines

I'm not sure in cases, where
Busybox is built, but not the default init system nor shell). The other packages who provide anything related to inetutils are not yet added, but of course they can be added
to act as dependencies.
The question is, why do anybody want to compile and use different implementations of one program? I mean what
could be the use case?

You assume that the user is doing a deliberate choice when enabling net-tools or inetutils. This is often not the case. A user bringing up a networking device is very likely to enable both packages. The version that eventually lands in the target will now be determined by the build order, and that may change from one build to another. We generally want make build results as consistent as possible. So, at the very least, we should warn the user in a comment that depends on BR2_PACKAGE_NET_TOOLS. I'm not sure this is enough, though.

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#6 lore raw

PATCH 1/1 inetutils: new package

Hi Baruch,

Quoted 18 lines · Baruch Siach

Hi K?roly,

Quoted 5 lines · K?roly Kasza

Buildroot handles these "race conditions" with the <package>_DEPENDENCIES variables.
I added Busybox as one (if selected), so Inetutils will always win over Busybox (that is probably
unnecessary btw, Busybox should always be built before other packages -

but

Quoted 8 lines

I'm not sure in cases, where
Busybox is built, but not the default init system nor shell). The other packages who provide anything related to inetutils are not yet added, but of course they can be added
to act as dependencies.
The question is, why do anybody want to compile and use different implementations of one program? I mean what
could be the use case?

Quoted 4 lines

You assume that the user is doing a deliberate choice when enabling net-tools
or inetutils. This is often not the case. A user bringing up a networking device is very likely to enable both packages.

Well, "You become responsible forever for what you've tamed." If you compile a Linux system from sources, you should know what you choose to include.
Otherwise just use some precompiled distribution.
(You are of course right, that this is often not the case).

Quoted 3 lines

The version that eventually
lands in the target will now be determined by the build order, and that may change from one build to another.

Yes, it works like that.

Quoted 4 lines

We generally want make build results as
consistent as possible. So, at the very least, we should warn the user in a comment that depends on BR2_PACKAGE_NET_TOOLS. I'm not sure this is enough, though.

I don't think that would fit to the current Buildroot habits. In these cases, where more than
one package provides the same tools, I tend to see the _DEPENDENCIES in .mk files.
I think it is just decided by package maintainers which package's tool is preferred over another.

I can make inetutils dependent on net-tools if net-tools is enabled, just like I did with busybox.
However, what if the user wants it the other-way?
Debian solves this by introducing /etc/alternatives, but I think in Buildroot it should just be
predefined which one to prefer.
Any suggestions?

Best regards,
Karoly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141031/2645174c/attachment.html>

#7 lore raw

PATCH 1/1 inetutils: new package

Hi all,

I investigated the matter further.
Looks like inetutils won't overwrite ifconfig or ping, because of a simple
reason: it installs the binaries elsewhere.
In these cases, both binaries will be present, and the $PATH will choose which to call.

However, it overwrites some binaries, whose packages will be added as conditional dependencies in v2.

Best regards,
Karoly

Quoted 68 lines · K?roly Kasza

Hi Baruch,

Quoted 19 lines · Baruch Siach

Hi K?roly,

Quoted 1 line · K?roly Kasza

Buildroot handles these "race conditions" with the

<package>_DEPENDENCIES

Quoted 4 lines

variables.
I added Busybox as one (if selected), so Inetutils will always win over Busybox (that is probably
unnecessary btw, Busybox should always be built before other packages -

but

Quoted 8 lines

I'm not sure in cases, where
Busybox is built, but not the default init system nor shell). The other packages who provide anything related to inetutils are not yet added, but of course they can be added
to act as dependencies.
The question is, why do anybody want to compile and use different implementations of one program? I mean what
could be the use case?

Quoted 4 lines

You assume that the user is doing a deliberate choice when enabling net-tools
or inetutils. This is often not the case. A user bringing up a networking device is very likely to enable both packages.

Well, "You become responsible forever for what you've tamed." If you compile a Linux system from sources, you should know what you choose to include.
Otherwise just use some precompiled distribution.
(You are of course right, that this is often not the case).

Quoted 4 lines

The version that eventually
lands in the target will now be determined by the build order, and that may
change from one build to another.

Yes, it works like that.

Quoted 6 lines

We generally want make build results as
consistent as possible. So, at the very least, we should warn the user in a
comment that depends on BR2_PACKAGE_NET_TOOLS. I'm not sure this is enough,
though.

I don't think that would fit to the current Buildroot habits. In these cases, where more than
one package provides the same tools, I tend to see the _DEPENDENCIES in .mk files.
I think it is just decided by package maintainers which package's tool is preferred over another.

I can make inetutils dependent on net-tools if net-tools is enabled, just like I did with busybox.
However, what if the user wants it the other-way?
Debian solves this by introducing /etc/alternatives, but I think in Buildroot it should just be
predefined which one to prefer.
Any suggestions?

Best regards,
Karoly

Signature · 5 lines
?dv,
KK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141101/6be86179/attachment.html>
#8 lore raw

PATCH 1/1 inetutils: new package

Dear K?roly Kasza,

Quoted 5 lines · K?roly Kasza

I investigated the matter further.
Looks like inetutils won't overwrite ifconfig or ping, because of a simple
reason: it installs the binaries elsewhere.
In these cases, both binaries will be present, and the $PATH will choose which to call.

This is not great. We don't really like having two variants of the same tool in the filesystem.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#9 lore raw

PATCH 1/1 inetutils: new package

Hi Thomas,

it is unpleasant indeed.
What is the Buildroot recommended method for these issues? Should I modify the install target to overwrite the existing tools?

Best regards,
Karoly

Quoted 20 lines · Thomas Petazzoni

Dear K?roly Kasza,

Quoted 2 lines · K?roly Kasza

I investigated the matter further.
Looks like inetutils won't overwrite ifconfig or ping, because of a

simple

Quoted 3 lines

reason: it installs the binaries elsewhere.
In these cases, both binaries will be present, and the $PATH will choose which to call.

This is not great. We don't really like having two variants of the same tool in the filesystem.

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Signature · 5 lines
?dv,
KK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141101/37ce39fa/attachment-0001.html>
#10 lore raw

PATCH 1/1 inetutils: new package

Dear K?roly Kasza,

Quoted 3 lines · K?roly Kasza

it is unpleasant indeed.
What is the Buildroot recommended method for these issues? Should I modify the install target to overwrite the existing tools?

I'd say it depends on the cases. Can you do a summary of the situation, i.e what tools inetutils installs and where, and how it compares with the installation location of the same tools by Busybox? That might help see how far we are, and what is the appropriate course of action.

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#11 lore raw

PATCH 1/1 inetutils: new package

Hi,

I wrote a small script to analyse which files are redundant, and if they will be overwritten or not.
I ran it against busybox, net-tools, iputils, rsh-redone, sysklogd and whois because I found that these
packages may overlap with inetutils' tools.

The same filename lines mean that an other file with the same name, but with a different path exists
(the compared package's path is in the brackets).
The same path lines mean that it would be overwritten at install.

busybox:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/ping (/bin/ping)
Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same filename /usr/libexec/syslogd (/sbin/syslogd) Found same path /usr/bin/traceroute
Found same path /usr/bin/tftp
Found same path /usr/bin/logger
Found same path /usr/bin/telnet
Found same filename /usr/libexec/inetd (/usr/sbin/inetd)

net-tools:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same path /usr/share/man/man1/dnsdomainname.1 Found same path /usr/share/man/man1/hostname.1

iputils:
Found same filename /usr/bin/ping6 (/bin/ping6)
Found same filename /usr/bin/ping (/bin/ping)

rsh-redone:
Found same path /usr/bin/rlogin
Found same path /usr/bin/rsh

sysklogd:
Found same filename /usr/libexec/syslogd (/sbin/syslogd)

whois:
Found same path /usr/share/man/man1/whois.1
Found same path /usr/bin/whois

I think a solution would be to disable inetutils' redundant tools:
whois, sysklogd, rlogin(d), rsh(d), ping, ping6, hostname, dnsdomainname, ifconfig, hostname.

After that, the only utility, that's not overwritten would be inetd from busybox, where a post-install hook
could simply alter the busybox symlink to point to inetutils' version instead.

I'm waiting for your opinions!

Best regards,
Karoly

Quoted 21 lines · Thomas Petazzoni

Dear K?roly Kasza,

Quoted 3 lines · K?roly Kasza

it is unpleasant indeed.
What is the Buildroot recommended method for these issues? Should I modify the install target to overwrite the existing tools?

I'd say it depends on the cases. Can you do a summary of the situation, i.e what tools inetutils installs and where, and how it compares with the installation location of the same tools by Busybox? That might help see how far we are, and what is the appropriate course of action.

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Signature · 5 lines
?dv,
KK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141102/7d546781/attachment.html>
#12 lore raw

PATCH 1/1 inetutils: new package

Hello all,

any comment on this one?
Shall I send the v2 with the redundant utilities disabled?

Best regards,
Karoly

Quoted 93 lines · K?roly Kasza

Hi,

I wrote a small script to analyse which files are redundant, and if they will be overwritten or not.
I ran it against busybox, net-tools, iputils, rsh-redone, sysklogd and whois because I found that these
packages may overlap with inetutils' tools.

The same filename lines mean that an other file with the same name, but with a different path exists
(the compared package's path is in the brackets).
The same path lines mean that it would be overwritten at install.

busybox:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/ping (/bin/ping)
Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same filename /usr/libexec/syslogd (/sbin/syslogd) Found same path /usr/bin/traceroute
Found same path /usr/bin/tftp
Found same path /usr/bin/logger
Found same path /usr/bin/telnet
Found same filename /usr/libexec/inetd (/usr/sbin/inetd)

net-tools:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same path /usr/share/man/man1/dnsdomainname.1 Found same path /usr/share/man/man1/hostname.1

iputils:
Found same filename /usr/bin/ping6 (/bin/ping6)
Found same filename /usr/bin/ping (/bin/ping)

rsh-redone:
Found same path /usr/bin/rlogin
Found same path /usr/bin/rsh

sysklogd:
Found same filename /usr/libexec/syslogd (/sbin/syslogd)

whois:
Found same path /usr/share/man/man1/whois.1
Found same path /usr/bin/whois

I think a solution would be to disable inetutils' redundant tools:
whois, sysklogd, rlogin(d), rsh(d), ping, ping6, hostname, dnsdomainname, ifconfig, hostname.

After that, the only utility, that's not overwritten would be inetd from busybox, where a post-install hook
could simply alter the busybox symlink to point to inetutils' version instead.

I'm waiting for your opinions!

Best regards,
Karoly

Quoted 13 lines · Thomas Petazzoni

Dear K?roly Kasza,

Quoted 3 lines · K?roly Kasza

it is unpleasant indeed.
What is the Buildroot recommended method for these issues? Should I modify the install target to overwrite the existing tools?

I'd say it depends on the cases. Can you do a summary of the situation, i.e what tools inetutils installs and where, and how it compares with the installation location of the same tools by Busybox? That might help see how far we are, and what is the appropriate course of action.

Quoted 8 lines

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

--

?dv,
KK

Signature · 5 lines
?dv,
KK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141110/298ac24d/attachment.html>
#13 lore raw

PATCH 1/1 inetutils: new package

In reply to Károly Kasza

Dear K?roly Kasza,

Quoted 49 lines · K?roly Kasza

I wrote a small script to analyse which files are redundant, and if they will be overwritten or not.
I ran it against busybox, net-tools, iputils, rsh-redone, sysklogd and whois because I found that these
packages may overlap with inetutils' tools.

The same filename lines mean that an other file with the same name, but with a different path exists
(the compared package's path is in the brackets).
The same path lines mean that it would be overwritten at install.

busybox:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/ping (/bin/ping)
Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same filename /usr/libexec/syslogd (/sbin/syslogd) Found same path /usr/bin/traceroute
Found same path /usr/bin/tftp
Found same path /usr/bin/logger
Found same path /usr/bin/telnet
Found same filename /usr/libexec/inetd (/usr/sbin/inetd)

net-tools:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same path /usr/share/man/man1/dnsdomainname.1 Found same path /usr/share/man/man1/hostname.1

iputils:
Found same filename /usr/bin/ping6 (/bin/ping6)
Found same filename /usr/bin/ping (/bin/ping)

rsh-redone:
Found same path /usr/bin/rlogin
Found same path /usr/bin/rsh

sysklogd:
Found same filename /usr/libexec/syslogd (/sbin/syslogd)

whois:
Found same path /usr/share/man/man1/whois.1
Found same path /usr/bin/whois

I think a solution would be to disable inetutils' redundant tools:
whois, sysklogd, rlogin(d), rsh(d), ping, ping6, hostname, dnsdomainname, ifconfig, hostname.

Quoted 6 lines

After that, the only utility, that's not overwritten would be inetd from busybox, where a post-install hook
could simply alter the busybox symlink to point to inetutils' version instead.

I'm waiting for your opinions!

Personally, I think we should keep all of those tools enabled, and simply fix the installation path, especially since inetutils is often the only one doing "weird" things, and all of the other packages agree on the location for all tools

First, for the "Found same path" cases above, I believe the solution is fairly easy: just make sure inetutils depends on the relevant packages so that they get overriden. For busybox it's easy, we always want the inetutils tools to override the busybox one. For the other packages, it might need a little bit more discussion as it's not immediately clear which package has the "best" implementation for each of the tools.

Now, for the "Found same filename" cases, the situation is quite clear:

* dnsdomainname: both busybox and net-tools install it to /bin, inetutils is the only one to choose /usr/bin. So the solution is to move it to /bin in inetutils.

* ping: both busybox and iputils install it to /bin, so same solution as above.

* hostname: both busybox and net-tools install it to /bin, so same solution.

* ifconfig: both busybox, and net-tools install it to /sbin, so same solution.

* syslogd: both busybox and sysklogd install it to /sbin, so same solution.

You can also try to pass --exec-prefix=/ in INETUTILS_CONF_OPTS and see if it improves the situation.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#14 lore raw

PATCH 1/1 inetutils: new package

Hello Thomas,

I like the idea to make every possible utility build-able, but this (as you mentioned) would mean that some utilities will have 3 different implementations to choose from in Buildroot (like ping). Of course fixing the paths of installed binaries should not be a problem.
To avoid possible conflicting situations, I would like to propose to use a menu-like option as nginx does, to make possible for inetutils programs to be chosen from a'la carte. Any objections?

Best regards,
Karoly

Quoted 101 lines · Thomas Petazzoni

Dear K?roly Kasza,

Quoted 49 lines · K?roly Kasza

I wrote a small script to analyse which files are redundant, and if they will be overwritten or not.
I ran it against busybox, net-tools, iputils, rsh-redone, sysklogd and whois because I found that these
packages may overlap with inetutils' tools.

The same filename lines mean that an other file with the same name, but with a different path exists
(the compared package's path is in the brackets).
The same path lines mean that it would be overwritten at install.

busybox:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/ping (/bin/ping)
Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same filename /usr/libexec/syslogd (/sbin/syslogd) Found same path /usr/bin/traceroute
Found same path /usr/bin/tftp
Found same path /usr/bin/logger
Found same path /usr/bin/telnet
Found same filename /usr/libexec/inetd (/usr/sbin/inetd)

net-tools:
Found same filename /usr/bin/dnsdomainname (/bin/dnsdomainname) Found same filename /usr/bin/hostname (/bin/hostname) Found same filename /usr/bin/ifconfig (/sbin/ifconfig) Found same path /usr/share/man/man1/dnsdomainname.1 Found same path /usr/share/man/man1/hostname.1

iputils:
Found same filename /usr/bin/ping6 (/bin/ping6)
Found same filename /usr/bin/ping (/bin/ping)

rsh-redone:
Found same path /usr/bin/rlogin
Found same path /usr/bin/rsh

sysklogd:
Found same filename /usr/libexec/syslogd (/sbin/syslogd)

whois:
Found same path /usr/share/man/man1/whois.1
Found same path /usr/bin/whois

I think a solution would be to disable inetutils' redundant tools:
whois, sysklogd, rlogin(d), rsh(d), ping, ping6, hostname, dnsdomainname, ifconfig, hostname.

Quoted 6 lines

After that, the only utility, that's not overwritten would be inetd from busybox, where a post-install hook
could simply alter the busybox symlink to point to inetutils' version instead.

I'm waiting for your opinions!

Personally, I think we should keep all of those tools enabled, and simply fix the installation path, especially since inetutils is often the only one doing "weird" things, and all of the other packages agree on the location for all tools

First, for the "Found same path" cases above, I believe the solution is fairly easy: just make sure inetutils depends on the relevant packages so that they get overriden. For busybox it's easy, we always want the inetutils tools to override the busybox one. For the other packages, it might need a little bit more discussion as it's not immediately clear which package has the "best" implementation for each of the tools.

Now, for the "Found same filename" cases, the situation is quite clear:

* dnsdomainname: both busybox and net-tools install it to /bin, inetutils is the only one to choose /usr/bin. So the solution is to move it to /bin in inetutils.

* ping: both busybox and iputils install it to /bin, so same solution as above.

* hostname: both busybox and net-tools install it to /bin, so same solution.

* ifconfig: both busybox, and net-tools install it to /sbin, so same solution.

* syslogd: both busybox and sysklogd install it to /sbin, so same solution.

You can also try to pass --exec-prefix=/ in INETUTILS_CONF_OPTS and see if it improves the situation.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Signature · 5 lines
?dv,
KK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141110/6ea4ad6a/attachment.html>