Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=491767 --- Comment #23 from Nalin Dahyabhai <nalin@xxxxxxxxxx> 2009-04-22 11:58:37 EDT --- (In reply to comment #22) > > It doesn't need to live in /%{_lib}, but by convention nsswitch modules, > > following largely from what glibc does with its own modules, have been put > > there anyway. > > Oh, good point. I guess nss_ldap is the one that's out of sorts, placing its > libraries under /usr/lib instead. That's as much about not being able to link with various static libraries any longer, and the shared versions of those libraries living in /usr, as anything else. > > In this case, though, it avoids having to deal with file conflicts or working > > something out with alternatives (which I actually tried doing, but trying to > > select the "right" one without requiring manual intervention didn't lend itself > > to any elegant solutions). > > Indeed, I can't imagine how you would do this with alternatives. Well, the idea was to hook runlevel changes (you can do that sort of thing with upstart, at least I thought you could) and call alternatives to select one or the other depending on whether the daemon was enabled at all for any runlevel, not that it worked right. > So where do we go from here? I think that from a packaging standpoint this is > good, but without support from the selinux policy it's not as useful and the > interactions with nscd are problematic (although it seems that at least some of > the problems I'm seeing are due to nscd's negative caching). If you can leave aside the no-policy-for-it problem while the rest of the packaging review continues, I can take a first stab at getting a policy together and then impose on dwalsh to work on fixing it. I'm okay with leaving this bug open until the policy's sorted out. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review