Comment 4 for bug 345137

Any issue of nscd being unstable is (and should be) a separate issue to optimal performance/operation, and achieving this through package recommends tags is the right mechanism.

The key problem is non-networking experts won't naturally somehow know to reach for nscd - in fact, it's counter-intuitive, as the package doesn't recommend or suggest it. To say that it shouldn't be used because of a bug, is a shade of "oh, there's a race in the linux pagecache. let's ship with it disabled..." (bad example I know).

Enabling it before the beta seems not unreasonable, as we can revert it before release, if there is issue; how much exposure will early alpha releases have in an enterprise environment with NIS? I've been running nscd with nis on ubuntu each of the past releases, which is why I'm driving this, and I want to ensure enterprise users see optimal performance through no special know-how.

A particular 'find' command on a small work dir of mine repetitively performs 9929 lookups over network. With nscd, it drops to 9. The average response time for each request is 2.02ms (fast, quiescent nis server), so a whole 2 seconds has been wasted waiting for NIS lookups, especially worse when all the dentries are in cache.

Should I add a debdiff adding it as a suggests field for now?