| Message ID | 1506953582-12965-1-git-send-email-casantos@datacom.ind.br |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [v3] nc: new virtual package providing "netcat" functionality | expand |
Hello, On Mon, 2 Oct 2017 11:13:02 -0300, Carlos Santos wrote: > Add the "nc" virtual package and modify netcat, netcat-openbsd and nmap > to become providers. > > Make the nmap recipe install "ncat" (with a symbolic link to nc) if the > BR2_PACKAGE_NMAP_NCAT option is set. Other programs (ncat, ndiff, etc.) > are still chosen via BR2_PACKAGE_NMAP, in the "Networking applications" > menu. > > So far the "nc" options available to build with uClibc were the ancient > GNU netcat and its Busybox double. Both lack features available in more > modern netcats like IPv6, proxies, and Unix sockets. > > Signed-off-by: Carlos Santos <casantos@datacom.ind.br> What is the benefit of having a virtual package for this ? Virtual packages are mainly useful when several variants of a given library provide the same API, but different implementations, and we have N consumers of this API. In such a case, a virtual package avoids having each consumer explicitly handle every possible provider of the API. However, in the case of netcat, I don't see the point. Yes, you can currently enable several packages that provide the netcat functionality, and they will step on each other in some combinations. But you can also enable several Web servers that will try to listen on port 80 at boot time, leaving only one functional, and still we're not going to have a "webserver" virtual package. So, I don't see where the problem is, and therefore I don't think a solution is necessary :-) Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, > What is the benefit of having a virtual package for this ? > Virtual packages are mainly useful when several variants of a given > library provide the same API, but different implementations, and we > have N consumers of this API. In such a case, a virtual package avoids > having each consumer explicitly handle every possible provider of the > API. > However, in the case of netcat, I don't see the point. Yes, you can > currently enable several packages that provide the netcat > functionality, and they will step on each other in some combinations. > But you can also enable several Web servers that will try to listen on > port 80 at boot time, leaving only one functional, and still we're not > going to have a "webserver" virtual package. > So, I don't see where the problem is, and therefore I don't think a > solution is necessary :-) FYI, this is my feeling as well. The current setup afaik only has issues if you enable more than one package providing a nc implementation (this solution fixes it by not allowing such setup), but I'm not sure if there's really a realistic use case where somebody would want to do this in the first place?
> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com> > To: "Carlos Santos" <casantos@datacom.ind.br> > Cc: buildroot@buildroot.org, "Maxime Hadjinlian" <maxime.hadjinlian@gmail.com> > Sent: Monday, October 2, 2017 4:18:40 PM > Subject: Re: [Buildroot] [PATCH v3] nc: new virtual package providing "netcat" functionality > Hello, > > On Mon, 2 Oct 2017 11:13:02 -0300, Carlos Santos wrote: >> Add the "nc" virtual package and modify netcat, netcat-openbsd and nmap >> to become providers. >> >> Make the nmap recipe install "ncat" (with a symbolic link to nc) if the >> BR2_PACKAGE_NMAP_NCAT option is set. Other programs (ncat, ndiff, etc.) >> are still chosen via BR2_PACKAGE_NMAP, in the "Networking applications" >> menu. >> >> So far the "nc" options available to build with uClibc were the ancient >> GNU netcat and its Busybox double. Both lack features available in more >> modern netcats like IPv6, proxies, and Unix sockets. >> >> Signed-off-by: Carlos Santos <casantos@datacom.ind.br> > > What is the benefit of having a virtual package for this ? My first solution just allowed the user to build and install ncat with a symlink to "nc". > Virtual packages are mainly useful when several variants of a given > library provide the same API, but different implementations, and we > have N consumers of this API. In such a case, a virtual package avoids > having each consumer explicitly handle every possible provider of the > API. There are three packages able to provide the "nc" command (four, if we count busybox). I want to allow the user to choose only one of them, unambiguously. > However, in the case of netcat, I don't see the point. Yes, you can > currently enable several packages that provide the netcat > functionality, and they will step on each other in some combinations. The problem with this approach is that it does not prevent the user from selecting netcat and/or openbsd-netcat along with nmap, leading to the same tricky situation we have now with BusyBox, coreutils and util-linux, which compete for the ownership os some commands. Right now the problem is solved (wiped down the carpet) by making coreutils depend on busybox, for instance, but this works just because the busybox install step does not override existing files. > But you can also enable several Web servers that will try to listen on > port 80 at boot time, leaving only one functional, and still we're not > going to have a "webserver" virtual package. I'm following your own example: check luainterpreter, mysql and udev. > So, I don't see where the problem is, and therefore I don't think a > solution is necessary :-) I admit that is not mandatory but I still believe that it would lead to a more organized selection of packages/features.
> From: "Peter Korsgaard" <peter@korsgaard.com> > To: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com> > Cc: "Carlos Santos" <casantos@datacom.ind.br>, "Maxime Hadjinlian" <maxime.hadjinlian@gmail.com>, > buildroot@buildroot.org > Sent: Monday, October 2, 2017 4:44:56 PM > Subject: Re: [PATCH v3] nc: new virtual package providing "netcat" functionality >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > Hi, > > > What is the benefit of having a virtual package for this ? > > > Virtual packages are mainly useful when several variants of a given > > library provide the same API, but different implementations, and we > > have N consumers of this API. In such a case, a virtual package avoids > > having each consumer explicitly handle every possible provider of the > > API. > > > However, in the case of netcat, I don't see the point. Yes, you can > > currently enable several packages that provide the netcat > > functionality, and they will step on each other in some combinations. > > > But you can also enable several Web servers that will try to listen on > > port 80 at boot time, leaving only one functional, and still we're not > > going to have a "webserver" virtual package. > > > So, I don't see where the problem is, and therefore I don't think a > > solution is necessary :-) > > FYI, this is my feeling as well. The current setup afaik only has issues > if you enable more than one package providing a nc implementation (this > solution fixes it by not allowing such setup), but I'm not sure if > there's really a realistic use case where somebody would want to do this > in the first place? I'm currenly working on porting libvirt to buildroor. It requires a modern "nc" command (with support for unix sockets) to provide remote access via ssh using virt-manager. Currently this is impossible with uClibc because openbsd-netcat depends on GLIBC. At the same time I think it's waste of space to install the full nmap suite just to have one command. By the way, nmap's ncat is the "nc" command used on Fedora Linux while Debian uses openbsd-netcat by default.
Hello Carlos, On Mon, 2 Oct 2017 17:09:55 -0300 (BRT), Carlos Santos wrote: > > Virtual packages are mainly useful when several variants of a given > > library provide the same API, but different implementations, and we > > have N consumers of this API. In such a case, a virtual package avoids > > having each consumer explicitly handle every possible provider of the > > API. > > There are three packages able to provide the "nc" command (four, if > we count busybox). I want to allow the user to choose only one of them, > unambiguously. I'm sorry, but I really don't think we want to go down this route. As I explained, there are lots of other packages in Buildroot that conflict with each other. If you select two web servers, they will compete to bind to port 80. If you select two SSH servers, they will compete to bind to port 22. And so on and so on. We are not going to add virtual packages for all of those cases. The only situation where virtual packages make sense is when we have multiple packages using an API provided by multiple packages (OpenGL, jpeg, etc.). > > But you can also enable several Web servers that will try to listen on > > port 80 at boot time, leaving only one functional, and still we're not > > going to have a "webserver" virtual package. > > I'm following your own example: check luainterpreter, mysql and udev. All of those are providing an implementation to other packages: - luainterpreter is used by all Lua modules, because they can support using different Lua interpreters - mysql because it provides a client library that is used by numerous packages - udev because it is provided either by systemd or by eudev, and is a library API used by a large number of packages. So, I'm sorry but no, we are not going to add a virtual packages for netcat. Best regards, Thomas
> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com> > To: "Carlos Santos" <casantos@datacom.ind.br> > Cc: buildroot@buildroot.org, "Maxime Hadjinlian" <maxime.hadjinlian@gmail.com> > Sent: Wednesday, October 4, 2017 6:20:08 AM > Subject: Re: [Buildroot] [PATCH v3] nc: new virtual package providing "netcat" functionality > Hello Carlos, > > On Mon, 2 Oct 2017 17:09:55 -0300 (BRT), Carlos Santos wrote: > >> > Virtual packages are mainly useful when several variants of a given >> > library provide the same API, but different implementations, and we >> > have N consumers of this API. In such a case, a virtual package avoids >> > having each consumer explicitly handle every possible provider of the >> > API. >> >> There are three packages able to provide the "nc" command (four, if >> we count busybox). I want to allow the user to choose only one of them, >> unambiguously. > > I'm sorry, but I really don't think we want to go down this route. ---8<--- OK, I sent a smaller patch which simply adds an option to build/install ncat.
diff --git a/package/Config.in b/package/Config.in index ccd42c7..0b81f85 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1665,11 +1665,10 @@ menu "Networking applications" source "package/mrouted/Config.in" source "package/mtr/Config.in" source "package/nbd/Config.in" + source "package/nc/Config.in" source "package/ncftp/Config.in" source "package/ndisc6/Config.in" source "package/netatalk/Config.in" - source "package/netcat/Config.in" - source "package/netcat-openbsd/Config.in" source "package/netplug/Config.in" source "package/netsnmp/Config.in" source "package/netstat-nat/Config.in" diff --git a/package/nc/Config.in b/package/nc/Config.in new file mode 100644 index 0000000..c599f0d --- /dev/null +++ b/package/nc/Config.in @@ -0,0 +1,84 @@ +config BR2_PACKAGE_NC + bool "nc (netcat)" + depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS + help + Select the desired "nc" command provider. + +if BR2_PACKAGE_NC + +choice + prompt "nc variant" + default BR2_PACKAGE_NETCAT + help + Select either the venerable netcat (default), netcat-openbsd + or nmap-ncat. + +config BR2_PACKAGE_NETCAT + bool "netcat" + select BR2_PACKAGE_HAS_NC + help + Netcat is a featured networking utility which reads and writes + data across network connections, using the TCP/IP protocol. + It is designed to be a reliable "back-end" tool that can be + used directly or easily driven by other programs and scripts. + At the same time, it is a feature-rich network debugging and + exploration tool, since it can create almost any kind of + connection you would need and has several interesting built-in + capabilities. + + http://netcat.sourceforge.net/download.php + +config BR2_PACKAGE_NETCAT_OPENBSD + bool "netcat-openbsd" + select BR2_PACKAGE_HAS_NC + depends on BR2_PACKAGE_LIBBSD_ARCH_SUPPORTS + depends on BR2_TOOLCHAIN_HAS_THREADS + depends on BR2_TOOLCHAIN_USES_GLIBC + depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS + select BR2_PACKAGE_LIBBSD + help + This OpenBSD rewrite of netcat, including support for IPv6, + proxies, and Unix sockets. Reads and writes data using TCP or + UDP protocol. It is designed to be a reliable "back-end" tool + that can be used directly or easily driven by other programs + and scripts. At the same time it is a feature-rich network + debugging and exploration tool, since it can create almost any + kind of connection you would need and has several interesting + built-in capabilities. + + https://packages.debian.org/sid/netcat-openbsd + +comment "netcat-openbsd needs a toolchain w/ glibc, threads" + depends on BR2_PACKAGE_LIBBSD_ARCH_SUPPORTS + depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_USES_GLIBC + depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS + +config BR2_PACKAGE_NMAP_NCAT + bool "nmap-ncat" + depends on BR2_INSTALL_LIBSTDCPP + depends on BR2_USE_MMU # fork() + depends on BR2_TOOLCHAIN_HAS_THREADS + select BR2_PACKAGE_NMAP + select BR2_PACKAGE_LIBPCAP + help + Ncat is a feature-packed networking utility which reads and + writes data across networks from the command line. Ncat was + written for the Nmap Project as a much-improved + reimplementation of the venerable Netcat. + +comment "nmap-nmap needs a toolchain w/ C++, threads" + depends on BR2_USE_MMU + depends on !(BR2_INSTALL_LIBSTDCPP && BR2_TOOLCHAIN_HAS_THREADS) + +endchoice + +config BR2_PACKAGE_HAS_NC + bool + +config BR2_PACKAGE_PROVIDES_NC + string + default "netcat" if BR2_PACKAGE_NETCAT + default "netcat-openbsd" if BR2_PACKAGE_NETCAT_OPENBSD + default "nmap" if BR2_PACKAGE_NMAP_NCAT + +endif diff --git a/package/nc/nc.mk b/package/nc/nc.mk new file mode 100644 index 0000000..e04b2bd --- /dev/null +++ b/package/nc/nc.mk @@ -0,0 +1,7 @@ +################################################################################ +# +# nc +# +################################################################################ + +$(eval $(virtual-package)) diff --git a/package/netcat-openbsd/Config.in b/package/netcat-openbsd/Config.in deleted file mode 100644 index 6df87ec..0000000 --- a/package/netcat-openbsd/Config.in +++ /dev/null @@ -1,25 +0,0 @@ -config BR2_PACKAGE_NETCAT_OPENBSD - bool "netcat-openbsd" - depends on BR2_PACKAGE_LIBBSD_ARCH_SUPPORTS - depends on BR2_TOOLCHAIN_HAS_THREADS - depends on BR2_TOOLCHAIN_USES_GLIBC - depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - select BR2_PACKAGE_LIBBSD - help - A simple Unix utility which reads and writes data across network - connections using TCP or UDP protocol. It is designed to be a - reliable "back-end" tool that can be used directly or easily driven - by other programs and scripts. At the same time it is a feature-rich - network debugging and exploration tool, since it can create almost - any kind of connection you would need and has several interesting - built-in capabilities. - - This package contains the OpenBSD rewrite of netcat, including - support for IPv6, proxies, and Unix sockets. - - https://packages.debian.org/sid/netcat-openbsd - -comment "netcat-openbsd needs a glibc toolchain w/ threads" - depends on BR2_PACKAGE_LIBBSD_ARCH_SUPPORTS - depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_USES_GLIBC - depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS diff --git a/package/netcat-openbsd/netcat-openbsd.mk b/package/netcat-openbsd/netcat-openbsd.mk index e1a6fee..5395f85 100644 --- a/package/netcat-openbsd/netcat-openbsd.mk +++ b/package/netcat-openbsd/netcat-openbsd.mk @@ -8,6 +8,8 @@ NETCAT_OPENBSD_VERSION = debian/1.105-7 NETCAT_OPENBSD_SITE = git://anonscm.debian.org/collab-maint/netcat-openbsd NETCAT_OPENBSD_LICENSE = BSD-3-Clause NETCAT_OPENBSD_LICENSE_FILES = debian/copyright +NETCAT_OPENBSD_PROVIDES = nc + NETCAT_OPENBSD_DEPENDENCIES = host-pkgconf libbsd # Ensure Busybox gets built/installed before, so that this package diff --git a/package/netcat/Config.in b/package/netcat/Config.in index 924069e..e69de29 100644 --- a/package/netcat/Config.in +++ b/package/netcat/Config.in @@ -1,13 +0,0 @@ -config BR2_PACKAGE_NETCAT - bool "netcat" - depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - help - Netcat is a featured networking utility which reads and writes data - across network connections, using the TCP/IP protocol. - It is designed to be a reliable "back-end" tool that can be used - directly or easily driven by other programs and scripts. At the - same time, it is a feature-rich network debugging and exploration - tool, since it can create almost any kind of connection you would - need and has several interesting built-in capabilities. - - http://netcat.sourceforge.net/download.php diff --git a/package/netcat/netcat.mk b/package/netcat/netcat.mk index eb7ddca..94786fc 100644 --- a/package/netcat/netcat.mk +++ b/package/netcat/netcat.mk @@ -8,5 +8,6 @@ NETCAT_VERSION = 0.7.1 NETCAT_SITE = http://downloads.sourceforge.net/project/netcat/netcat/$(NETCAT_VERSION) NETCAT_LICENSE = GPL-2.0+ NETCAT_LICENSE_FILES = COPYING +NETCAT_PROVIDES = nc $(eval $(autotools-package)) diff --git a/package/nmap/Config.in b/package/nmap/Config.in index 79f587a..3203c3e 100644 --- a/package/nmap/Config.in +++ b/package/nmap/Config.in @@ -1,8 +1,12 @@ config BR2_PACKAGE_NMAP + bool + +config BR2_PACKAGE_NMAP_NMAP bool "nmap" depends on BR2_INSTALL_LIBSTDCPP depends on BR2_USE_MMU # fork() depends on BR2_TOOLCHAIN_HAS_THREADS + select BR2_PACKAGE_NMAP select BR2_PACKAGE_LIBPCAP select BR2_PACKAGE_PCRE help diff --git a/package/nmap/nmap.mk b/package/nmap/nmap.mk index 37720e2..705687d 100644 --- a/package/nmap/nmap.mk +++ b/package/nmap/nmap.mk @@ -7,12 +7,14 @@ NMAP_VERSION = 7.40 NMAP_SITE = http://nmap.org/dist NMAP_SOURCE = nmap-$(NMAP_VERSION).tar.bz2 -NMAP_DEPENDENCIES = libpcap pcre +NMAP_DEPENDENCIES = libpcap NMAP_CONF_OPTS = --without-liblua --without-zenmap \ --with-libdnet=included --with-liblinear=included \ - --with-libpcre="$(STAGING_DIR)/usr" --without-ncat + --with-libpcre="$(STAGING_DIR)/usr" NMAP_LICENSE = GPL-2.0 NMAP_LICENSE_FILES = COPYING +NMAP_PROVIDES = nc + # needed by libpcap NMAP_LIBS_FOR_STATIC_LINK += `$(STAGING_DIR)/usr/bin/pcap-config --static --additional-libs` @@ -35,6 +37,9 @@ else NMAP_CONF_OPTS += --without-openssl endif +ifeq ($(BR2_PACKAGE_NMAP_NMAP),y) + +NMAP_DEPENDENCIES += pcre # ndiff only works with python2.x ifeq ($(BR2_PACKAGE_PYTHON),y) NMAP_DEPENDENCIES += python @@ -42,4 +47,25 @@ else NMAP_CONF_OPTS += --without-ndiff endif +else # only ncat + +NMAP_CONF_OPTS += --without-ndiff --without-zenmap --without-nping --without-nmap-update +define NMAP_BUILD_CMDS + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) build-ncat +endef +define NMAP_INSTALL_TARGET_CMDS + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) install-ncat +endef + +endif + +ifeq ($(BR2_PACKAGE_NMAP_NCAT),y) +define NMAP_INSTALL_NCAT_SYMLINK + ln -fs ncat $(TARGET_DIR)/usr/bin/nc +endef +NMAP_POST_INSTALL_TARGET_HOOKS += NMAP_INSTALL_NCAT_SYMLINK +else +NMAP_CONF_OPTS += --without-ncat +endif + $(eval $(autotools-package))
Add the "nc" virtual package and modify netcat, netcat-openbsd and nmap to become providers. Make the nmap recipe install "ncat" (with a symbolic link to nc) if the BR2_PACKAGE_NMAP_NCAT option is set. Other programs (ncat, ndiff, etc.) are still chosen via BR2_PACKAGE_NMAP, in the "Networking applications" menu. So far the "nc" options available to build with uClibc were the ancient GNU netcat and its Busybox double. Both lack features available in more modern netcats like IPv6, proxies, and Unix sockets. Signed-off-by: Carlos Santos <casantos@datacom.ind.br> --- Changes v1->v2: - Prevent build error Makefile:537: *** nmap is in the dependency chain of nc that has \ added it to its _DEPENDENCIES variable without selecting it or \ depending on it from Config.in. Stop. Changes v1->v2: - Remove package/netcat-openbsd/Config.in (was left empty) --- package/Config.in | 3 +- package/nc/Config.in | 84 ++++++++++++++++++++++++++++++++ package/nc/nc.mk | 7 +++ package/netcat-openbsd/Config.in | 25 ---------- package/netcat-openbsd/netcat-openbsd.mk | 2 + package/netcat/Config.in | 13 ----- package/netcat/netcat.mk | 1 + package/nmap/Config.in | 4 ++ package/nmap/nmap.mk | 30 +++++++++++- 9 files changed, 127 insertions(+), 42 deletions(-) create mode 100644 package/nc/Config.in create mode 100644 package/nc/nc.mk delete mode 100644 package/netcat-openbsd/Config.in