Re: [ITP] Inetutils 1.9.4

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Hi Daniel,

On Feb 16 17:28, D. Boland wrote:
> Corinna Vinschen wrote:
> >On Feb 13 07:56, D. Boland wrote:
> >>Corinna Vinschen wrote:
> >>>On Feb  7 18:55, D. Boland wrote:
> >>>>Some programs in the inetutils suite are packaged already:
> >>>>[...]
> >>>>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?
> >>[...]
> >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.

Let's use modern Linux distros as role model, please.

> >- 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.

Ok.  It would just be nice if your service installer scripts would
follow the technique used by other service installer scripts and not
work entirely differently.

> >- 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

That's because ping is using raw sockets which are restricted to
admins.  Sadly Windows doesn't support the SUID bit...

Linux' traceroute supports the -U flag which uses UDP packages.  That
might be a default option for non-admin accounts, if this traceroute
supports UDP tracing as well, wouldn't it?

> >- 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?

There are two points here.

One, I didn't say that you have to take the patches as is.  They might
partially not even be necessary anymore.  I asked you if you have
*checked* them.  Some of them might contain stuff which should stay
available one way or the other to be backward compatible with the former
version of inetutils (especially inetd).  The missing O_BINARY stuff
looks suspicious, for instance.

Two, of course it's preferably if necessary patches go upstream.  But
upstream might not even know that we're using their package.  And if the
old maintainer didn't communicate with upstream, it would probably make
sense if the new maintainer would try to pick up.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature