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 04:51 EST ------- (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. That is one of the motivations of the project being BSD instead of lgpl. I see two choices. I can either a) add the above text as a comment in the specfile or b) remove the static libs entirely from the rpm. I suppose option B has the effect of people then complaining that the openais package doesn't have the static libs. Rather more important for me is inclusion of the package in Fedora Core 6, so if static libs are non-negotiable they can be removed and I'll deal with the complaining from the user community. Regarding issue #2: I am not sure which unowned dirs I am missing. Would you be kind enough point them out to me? Thanks. Regarding issue #3: Somehow I uploaded the wrong specfile to the site. I did fix the optflags issue as per Paul's suggestion, and checked the specfile on my laptop has this change. I'll upload another tomorrow with the unowned dirs change (if you could point out the unowned dirs). rpmlint doesn't seem to complain about this. Regarding issue #4: Could you please provide an argument for packaging conventions being way off from common conventions in Linux. What exactly is wrong? I need to understand what is unsuitable about the packaging methods so they can be fixed (or I can convince you otherwise). I'll take a stab anyway: 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. Hence using "libsaamf.so.1.0" is not suitable. First it would not be compliant with the specification, second code portability would be reduced. I know the naming is obnoxious. The libraries should go into a separate library (and this is indeed the default of upstream) so that different SA Forum implementations may be tried on the same system. Since the filenames of the libraries are defined in the spec, if we installed to /usr/lib or /usr/lib64, it would prevent people from installing alternative implementations. The plugins (the .lcrso files) are a mechanism for exporting interfaces and supporting "Live Component Replacement" ie: replacing a plugin that is already loaded with a replacement component without service interruption. This is not really a plugin and a shared object doesn't get the job done. It is more of a complete component providing a specific service (for example, we have an object database component which is never used directly by any APIs). If you have a suggestion as to where these should "live" rather then /usr/lib/lcrso or /usr/lib64/lcrso, I'd entertain getting this changed upstream. As is, we intend to produce various other lcrso components for use by various projects (and our lcrso's are totally reusable). Regards -steve -- 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 Fedorafirstname.lastname@example.org http://www.redhat.com/mailman/listinfo/fedora-package-review