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 mhalcrow@xxxxxxxxxx 2007-06-08 12:50 EST ------- Kevin wrote: > Thanks for looking at this! > > We had gotten rid of the rpath in the past... looks like it's crept back. > Will get that fixed. 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. > >1) keyutils, openssl, pam requirements should be superfluous - library > >dependencies take care of this > > ok. Removed. > > >2) kernel requires are tricky. Generally, we do > > > >Conflicts: kernel < 2.6.19 > > > >as there's no reason, for example, to pull a kernel into a buildroot. > > Well, the tricky part here is we need to require a kernel with ecryptfs.ko in > it. For F-7 and devel no problems, as all of them have it. For FC-6 however, the > early kernels didn't, and the updated ones do. I thought that the error end > users get from yum on Requires is more usefull than Conflicts? > > >That's bad; these shouldn't be linked against things in /usr/lib. (Yes, some > >people still run /usr separate.) Moreover, I suspect that both of these will > >also dlopen the plugins in $(libdir)/ecryptfs? > > Thats a good Question. Michael? Any thoughts? 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. It sounds like the key modules shipping with the ecryptfs-utils package would best be statically linked too. > > -devel: what, if anything, will ever build against this? If there's nothing, > >it may not be worth shipping. (Also,does this package maintain a stable ABI?) > > I don't know of anything... Michael? 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. The exported symbols in libecryptfs can be considered stable. Mike -- 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