Bug 121989

Summary:	inetd not replaced with xinetd (when updating from 9.2 to 10.0)
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Ulrich Windl <Ulrich.Windl>
Component:	Update Problems	Assignee:	Petr Ostadal <postadal>
Status:	RESOLVED WORKSFORME	QA Contact:	Klaus Kämpf <kkaempf>
Severity:	Normal
Priority:	P5 - None	CC:	kukuk
Version:	Final
Target Milestone:	---
Hardware:	Other
OS:	All
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Ulrich Windl 2005-10-10 15:13:23 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?

Comment 1 Thorsten Kukuk 2005-10-10 16:38:35 UTC

No, the replacement should not happen automatically.

We need a tcpd shared library compat package (anyways because of SLES10).

Comment 2 Michael Radziej 2005-10-10 17:25:25 UTC

Hmm, Thorsten, then this is your business, isn't it?

Comment 3 Thorsten Kukuk 2005-10-10 17:33:38 UTC

I have no idea why it should be.

Comment 5 Petr Ostadal 2006-01-16 10:48:54 UTC

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?

Comment 6 Thorsten Kukuk 2006-01-16 10:57:17 UTC

I don't get any depency problems, too. SLES9/9.1 inetd works fine on
SLES10 Preview4.

Comment 7 Ulrich Windl 2006-01-16 14:03:59 UTC

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.

Comment 8 Petr Ostadal 2006-01-19 16:33:43 UTC

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?

Comment 9 Thorsten Kukuk 2006-01-19 17:02:50 UTC

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.