inetutils: new package
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
@@ -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
@@ -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
@@ -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
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, uucpdSigned-off-by Karoly Kasza <[email protected]>--- 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.mkpackage/Config.in +3
-0@@ -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@@ -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_WCHARpackage/inetutils/inetutils-01-PATH_PROCNET_DEV.patch new file +8
-0@@ -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.c2012-01-09
11:45:35.000000000 -0500
++++inetutils-1.9.1/ifconfig/system/linux.c2012-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 voidpackage/inetutils/inetutils.hash new file +2
-0@@ -0,0 +1,2 @@ +# calculated after checking PGP signature (signed by ams at gnu.org) +sha256e3783372540772bbadd6aa2c90f8a75511db4e7d40bbfa37ffdb1bc7a9697f3e inetutils-1.9.2.tar.xzpackage/inetutils/inetutils.mk new file +68
-0@@ -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 actuallyinstalled.
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
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, whoisifconfig 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>
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, whoisifconfig 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 -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 choosewhatever
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, whoisifconfig 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>
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 -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 onBR2_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>
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 onBR2_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_DEPENDENCIESin .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>
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
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 asimple
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>
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
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>
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.1Found same path/usr/share/man/man1/hostname.1iputils:
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/rshsysklogd:
Found same filename/usr/libexec/syslogd(/sbin/syslogd)whois:
Found same path/usr/share/man/man1/whois.1
Found same path/usr/bin/whoisI 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,
KarolyQuoted 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>
PATCH 1/1 inetutils: new package
In reply to Károly KaszaDear 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.1Found same path/usr/share/man/man1/hostname.1iputils:
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/rshsysklogd:
Found same filename/usr/libexec/syslogd(/sbin/syslogd)whois:
Found same path/usr/share/man/man1/whois.1
Found same path/usr/bin/whoisI 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
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.1Found same path/usr/share/man/man1/hostname.1iputils:
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/rshsysklogd:
Found same filename/usr/libexec/syslogd(/sbin/syslogd)whois:
Found same path/usr/share/man/man1/whois.1
Found same path/usr/bin/whoisI 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_OPTSand 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>