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.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
