On Fri, Jul 07, 2006 at 07:18:50PM +1000, Peter Jeremy wrote: > On Fri, 2006-Jul-07 10:06:55 +0400, Michael Bushkov wrote: > >1. Having nss_ldap in the source gives an ability to use nss_ldap right > >"out of the box" and equals it in rights with such nsswitch sources as NIS > >and DNS. If we have NIS in the base system, I don't see any reasons not to > >have nss_ldap. Besides, i'm sure, having nss_ldap in the base will make > >users feeling more comfortable when dealing with it. > > I don't think this follows. Things like X and perl can be installed > from sysinstall with mininal effort. I'd prefer to make it easier > to install nss_ldap as a package than have it in the base system. IMO there's a substantial difference between something like X or perl and an authentication and authorization system in terms of the benefits of integration. Having X or perl broken because of a version mismatch or what not is annoying, but you can generally work around it particularly on a server. Having all access other than console single user broken due to breaking your login stuff is not so fixable. > >2. I guess, we'll have to rewrite nss_ldap by ourselves sooner or later > >(actually, I can do it), so current nss_ldap import can be viewed as the > >first stage of the plan. > > It would seem cleaner to implement our own nss_ldap from scratch > rather than importing a GPL one and then replacing it. IMHO, having > the GPL nss_ldap in the tree would make it harder to import another > one. Once people start using nss_ldap, they are going to get very > picky about a replacement being bug-for-bug compatible. That's a valid concern. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC