Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecryptfs-utils - Linux eCryptfs utilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218556 ------- Additional Comments From notting@xxxxxxxxxx 2007-06-08 13:02 EST ------- (In reply to comment #57) > I thought I had addressed this issue with the --disable-rpath > configure flag. I don't think there's anything funny in my makefiles > that should re-introduce it. It's probably libtool. See the 'Removing RPATH' section of http://fedoraproject.org/wiki/Packaging/Guidelines - you may need some of the sed goo there. > It makes sense to link these statically. I will make it so in the next > ecryptfs-utils release. > > > Yes, those .so's under libdir/ecryptfs/ do dlopen the so's. > > This sounds like something for upstream to change? > > The files in libdir/ecryptfs/ are pluggable key modules, sort of like > OpenSSL engines in /usr/lib/engines/. > > However, they are necessary in order to insert the key for the given > key type into the user session keyring, and hence are necessary in > order to mount. Into the *user session* keyring? If it's not being done until the user logs in,you can assume that /usr is available, so it's not an issue. > libecryptfs exists specifically to allow others to write their own > utilities (a GUI, for instance) to work with eCryptfs key management > functions. For instance, anyone who wants to write their own pluggable > key modules to interface with their own key management system will > need the -devel package. OK, thanks. Re: kernel requires vs. conflicts; conflicts is what we've historically done in packages such as initscripts, hal, and so on that don't work with older kernels. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review