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: openais standards based cluster framework https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192889 ------- Additional Comments From [EMAIL PROTECTED] 2006-05-26 05:28 EST ------- (In reply to comment #19) > (In reply to comment #18) > > - Still shipping static libs > > - Packages still contain unowned dirs > > - Compilation still doesn't honor optflags > > > > Without having looked into details, packaging of dynamic libs/plugins seems > > to > > be way off from any common conventions on Linux. > > > > Thank you for your comments. > > Regarding issue #1 > : > Based upon feedback with the user community there are many people which would > like to link statically to the libraries. Yes, some undereducated users and some undereducated maintainers are stubborn about static libs. > I see two choices. Nope, you have only have these choices: 1. Not shipping static libs 2. Prove why you must ship static libs. > Regarding issue #2 > : > I am not sure which unowned dirs I am missing. Would you be kind enough point > them out to me? Thanks. Pardon, but this is your job. Install and deinstall your packages and check which dirs remain on the file system or check the output of rpm -qlp <your-packages> Hint: rpm -qlp openais-0.76-1.0.i386.rpm | grep share/doc rpm -qlp openais-0.76-1.0.i386.rpm | grep etc > Regarding issue #3 > : > Somehow I uploaded the wrong specfile to the site. I used the src.rpm from comment #17. > Regarding issue #4 > : > Could you please provide an argument for packaging conventions being way off > from common conventions in Linux. > What exactly is wrong? Almost everything: >From the non-devel package: /usr/lib/openais/lcrso/service_amf.lcrso >From the devel package: /usr/lib/openais/libSaAmf.a /usr/lib/openais/libSaAmf.so.1.0 Now compare this against any arbitrary package. Devel package: libXXX.so -> libXXX.so.1.2.3 non-devel package: libXXX.so.1 -> libXXX.so.1.2.3 > The packaging of the dynamic libs as files "libSaAmf.so.1.0" as an example is > required by the SA Forum specification. We try to match the specification as > closely as possible for code portability between implementations. Any such approach is doomed to fail. Nothing about shared library naming is portable, but you can't avoid using the conventions and implications of the OS, so you must be using the conventions of the OS. Wrt. plugins, there is no convention. Their names can be arbibrarily choosen. IMO, xxxxxso is one of the weirdest approaches I've seen. In most cases their are named "*.so". -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
