Bugzilla – Bug 121989
inetd not replaced with xinetd (when updating from 9.2 to 10.0)
Last modified: 2006-01-19 17:02:50 UTC
When trying an update from 9.2 to 10.0 selecting to replace installed packages only (and resolve dependencies), the tcpd does to fulfill the requirements of the old inetd. Resolutions suggested are: not to update tcpd (probably causeing a lot of new problems), or to remove inetd (without suggesting to use xinetd instead) Shouldn't the replacement happen automatically?
No, the replacement should not happen automatically. We need a tcpd shared library compat package (anyways because of SLES10).
Hmm, Thorsten, then this is your business, isn't it?
I have no idea why it should be.
Strange, when I'd like prepare tcpd-compat I didn't found any problem of nonresolved dependencies. tcp form 10.0 (or STABLE) doesn't differ from 9.2 (only small gcc patches were added). --requires and --provides are equal. I tried install inetd from sles9-x86_64 on STABLE and it worked without problems (I didn't try yast update). Ulrich, could you please specify the problematic dependencies?
I don't get any depency problems, too. SLES9/9.1 inetd works fine on SLES10 Preview4.
In reply to comment #5: I always had preferrex "inetd" over "xinetd" as long as possible. Seems "inetd" was available for 9.2, but isn't in 10.0 (9.3 was skipped). So if the user who is unaware that "inetd" no longer exists, deselects installation of "xinetd" in software selection, the dependency resolver seemed to be unable to suggest to install "xinetd" (it seems). Maybe the problem had been fixed in the meantime. Also this is not the most common procedure when updating.
We can obsoleted and provided inetd by xinetd, but when some one would like keep inetd he can have problem. Thorsten, what do you think about it?
I cannot reproduce any of the Ulrich problems. Updates from a release with inetd to a newer one are fine. If Ulrich deselcts xinetd and there is no inetd, this no bug, too. Obsoleting inetd by xinetd is a bad idea, the old inetd still works fine and we are not able to convert the inetd.conf to a xinetd configuration.