[Bug 192889] Review Request: openais standards based cluster framework

[bugzilla at redhat.com]

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 sdake at redhat.com  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.