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: keyutils - Kernel key management userspace utilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190664 ------- Additional Comments From rc040203@xxxxxxxxxx 2006-05-05 08:16 EST ------- (In reply to comment #4) > > Well, how comes the rest of the world is not following this proposal? > > glibc and binutils both use it. > > The only thing that matters is the SONAME, the library's filename is largely > > ignorable (c.f. info libtool, for why this naming is considered harmful). > > Well, in my libtool info page, in section 6.4 (Managing release information), > it holds up `libbfd-2.9.0.so' as the example of naming. Yes, binutils is a counter example of good practice and glibc is Drepper's playground - Almost everybody else is not following this bad habits. > > With this, I end up with > > /lib/libkeyutils-1.1.1.fc4.so > > The library's filename is, as you said, largely ignorable; and the fact that > the library version number contains 'fc4' will not cause binary > incompatibility, since the SONAME is set to the interface symlink > (/lib/keyutils.so.N). > > What would you suggest? You should learn to destinguish library API-versioning from package versioning. > Anyway, I've fixed the Makefile problem and the double-slash problem: > > SPEC URL: > http://people.redhat.com/~dhowells/keyutils/keyutils-1.1-2/keyutils.spec > SRPM URL: > http://people.redhat.com/~dhowells/keyutils/keyutils-1.1-2/keyutils.spec > > The static library should be there as this library wraps some system calls > that aren't available through glibc. Hmm? I fail to understand this, because your binaries are dynamically linked against libkeyutils.so. I am not going to approve this package in it's current shape. -- 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