Buchan Milne wrote:

But, if you were to install a vanilla Windows XP (without the hardware vendor's customised release, or their support pack), you would be in a similar position. I don't think comparing hardware driver support (for hardware which has only been supported since after the distro shipped) is necessarily the same as requiring latest and greatest versions of software (when the distros in many cases shipped the "stable" release in the first place).

Perhaps it was a poor analogy. The point is, the distro shipped with a driver that claimed to support my hardware, and it didn't work correctly. That's different from having no driver at all, no claimed support at all...

...

The problems are exacerbated by the clumsy design of the pam_ldap/nss_ldap mechanisms, which cause system-level functionality to pollute user-program namespaces. If distros would take the proper steps to hide the symbols of their dynamically loaded pam/nss modules from user code, then most of the compatibility issues would disappear.

Should this not rather be fixed once upstream?

Upstream software can be much better supported by the distributions when it's default installation is sane ...

I think the steps required vary depending on what other library dependencies are involved, and only the people compiling the package can determine that.

Consider that most distributions now ship with ~ 3000 packages in a somewhat comprehensive distribution (and anything from 10 000 to 30 000 if you include the full repos), and you'll agree that the distribution can't fix *all* bugs in *all* software ... it works much better if it's fixed once upstream.

I don't know if you can call a basic design flaw (nss architecture) a simple bug. In that case, you have to complain to the glibc maintainers - the problem goes further upstream than you realize. Also if you are releasing a distro, you are implicitly promising that all of the software you provide actually works, and works in the combination that you distribute. The upstream folks don't have any control over how you combine their individual pieces. The distro provider is the only entity that has that control, and has that ultimate responsibility.

Time has shown that in practice, the majority of distro providers don't have the manpower or the competence to back up their promise. I.e., many of the players in that game should be doing something else with their lives...

...

I have a feeling that not enough people complain to their distro vendors about these problems, and so the distros continue to pretend the problems don't exist.

Or, maybe: 1)people need to file more bugs on nss_ldap 2)bugs filed on nss_ldap etc. should be addressed more aggressively

Which is presently not a topic for the OpenLDAP-Software list. (It could become such, if someone were to contribute an nss_ldap module to the OpenLDAP repository.)