Re: [ITP] Inetutils 1.9.4

["D. Boland" <daniel at boland dot nl>]

Hi Corinna,

Corinna Vinschen wrote:
> Hi Daniel,
>
> On Feb 13 07:56, D. Boland wrote:
> > Hi Corinna,
> >
> > Corinna Vinschen wrote:
> > > On Feb  7 18:55, D. Boland wrote:
> > > > Some programs in the inetutils suite are packaged already:
> > > >
> > > > * hostname
> > > > * whois
> > > > * tftp
> > > > * tftp-server
> > > >
> > > > So I added these on the 'required' lines.
> > > They are not actually *required* to run inetd, right?  Does it really
> > > make sense to add them as require packages then?
> > They belong to the package. A user expects them in there and would have
> > to piece the package back together. Why does it make sense to leave them
> > out?
>
> These tools are provided separately in many Linux distros for quite
> some time, and while those tools can be started by inetd, inetd
> doesn't require them and they don't require inetd (xinetd is perfectly
> capable of replacing inetd).

I don't see why this makes sense. The ping, hostname, whois and tftp 
programs *do* belong to the inetutils package, right? But if you insist, 
i'll comply.

> > > > Also, the following include files are needed:
> > > >
> > > > * /usr/include/netinet/icmp6.h
> > > > * /usr/include/netinet/ip_var.h
> > > >
> > > > There has been discussion on including the icmp6.h file in Cygwin 2.3.0.
> > > Can you check if icmp6.h from FreeBSD
> > > https://svnweb.freebsd.org/base/head/sys/netinet/icmp6.h?revision=279531&view=co
> > > does the trick when copied to /usr/include/netinet?  If so, I add this file
> > > to the repo.
> > If I use the FreeBSD version I get:
> >
> > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../lib -I../lib -I../libinetutils
> > -I../libicmp    -O2 -pipe -Wimplicit-function-declaration -MT ping6.o -MD
> > -MP -MF .deps/ping6.Tpo -c -o ping6.o ping6.c
> > ping6.c: In function 'ping_init':
> > ping6.c:844:37: error: 'ICMP6_FILTER' undeclared (first use in this
> > function)
> >      setsockopt (fd, IPPROTO_ICMPV6, ICMP6_FILTER, &filter, sizeof
> > (filter));
>
> That won't work.  Ever.  Using RAW sockets requires administrator
> privileges.  Apart from that, WinSock setsockopt does not at all support
> settings for the IPPROTO_ICMPV6 protocol family.  That's what the
> 32 bit ping package

OK. I'll leave the ping6 program out.

> I took a (not so) quick glance over the binary packages and there are
> some problems:
>
> - etc/defaults/etc/init.src.sh has 000 perms.

I'll fix that.

> - etc/defaults/etc/shells collides with the already provided file from
>   the base-files package.

I'll remove it.

> - usr/bin/inetutils-server-config installs inetd and syslogd in one
>   go.  That's a no no.  There should be two installation scripts since
>   you can't expect that a user who wants one service also wants the
>   other one.  Some people would probably like to stick to the Windows
>   logging, or install syslog-ng.
>
> - Apropos syslog-ng: syslogd potentially collides with syslog-ng.
>   However, instead of reusing the existing /usr/bin/syslogd-config
>   script, your new scripts don't check for an existing syslog-ng
>   installation at all.

I'll create inetutils-inetd-config and inetutils-syslogd-config. The 
latter will check for syslog-ng existance.

> - You removed the etc/defaults/etc/xinetd.d files.

I'll put them in.

> - You removed the /usr/bin/iu-config file, which was specificially
>   created to allow running under the cyg_server account for the known
>   reasons of being able to switch the user context(*).  Your scripts
>   enforce file ownership and service start under the SYSTEM account.
>   That's why the csih package exists for service installation scripts to
>   use for stuff like that.  Please have a look into the old
>   /usr/bin/iu-config file.

I'll restore the iu-config script.

> - usr/bin/ping collides with the ping package.

I'll remove ping.

> - sbin/ifconfig is mostly non-functional since Cygwin doesn't support
>   most of the functionality.  Do you really want to maintain it?
>
> - usr/bin/traceroute is non-functional:
>
>     $ traceroute.exe www.wdr.de
>     traceroute to e2636.g.akamaiedge.net (104.90.150.230), 64 hops max
>     traceroute: socket: Operation not permitted

That's because you're not in Administrator mode. Ping (from Atzeri's 
package) does the same. The error message ultimately comes from the 
'sendto' function, which is in cygwin1.dll

> - What also irritates me is that almost none of the patches from the
>   former package made it into your version.  Did you actually check the
>   patches from the current 1.9.1 source package and made sure that they
>   are really not required anymore, especially concerning O_BINARY/O_TEXT
>   mode, authentication, exception handling, and, generally, backward
>   compatibility?

What surprised me was the sheer number of patches. A whopping 573 of 
them. Are they bug-fixes? Features? Shouldn't both be sent upstream? 
What about the dont-mess-with-userspace rule? You once told me
that "we mostly strive to make Cygwin accommodate user space".

I'm not sure if I want to adopt inetutils with all these patches. It 
feels like a can of worms. I cannot find any explanations for the 
patches in the README files. Those patches are going to haunt me. I am a 
systems-programmer for 20 years now. And I learnt Torvald's first rule 
of kernel programming the hard way.

Please let me adopt the package in a clean way. If a parent adopts a 
child, there will be new rules. The real parents didn't want the child, 
or couldn't keep the child for unknown reasons. I don't mess with the 
child and it will love me for it. I'll take full resposibility for not 
messing with the child ;-)

Seriously, I really think it is fair to re-negotiate if and how I will 
mess with inetutils. I'm the new maintainer, right? The concerns about 
authentication I understand, but isn't a big issue. It's in the new, 
much smaller patch. And aren't things like O_BINARY/O_TEXT mode and 
exception handling a concern of the upstream maintainers?

Sincerely,
Daniel