[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 paul at city-fan.org  2006-06-05 06:15 EST -------
(In reply to comment #23)
> (In reply to comment #22)
> > "man openais_overview" mentions adding a user "ais" to the system. Shouldn't the
> > package be doing that?
> > 
> 
> yes check out the new source rpm I have added the functionality.  Unfortunately
> I am not sure which UID to use.  Is there a UID registry maintained for fedora?

There probably is but I don't know where (Bill Nottingham will probably know).
However, unless there is a requirement for the account to have the same UID
across different machines on a network (e.g. if they required shared access to
the same files using NFS), you could just use the "-r" option of useradd to
create a systen account and not worry about the exact UID.

Should any of the package files be owned by this user?

>> Would it be approriate to do a "/sbin/service openais condrestart" in %post to
>> restart the service if it's running when the main package is upgraded?
>> 
>
> good suggestion and that has been added.

Please add "|| :" to ensure that an initscript problem doesn't damage the rpm
transaction.

You also need to add /sbin/service to Requires(post)

> > I think %{_libdir}/openais/lib*.so.* should be in the main package, and only
> > %{_libdir}/openais/lib*.so should be in the devel package. This would be
> > consistent with other packages. If the libs are only needed for the devel
> > package, then the /etc/ld.so.conf.d/openais-*.conf file should be in the devel
> > package and the scriptlet calls of ldconfig should be in the devel package too.
> > 
> 
> I don't understand why lib*.so.* should be in main and lib*.so be in devel?  As
> an example, consider libevs.
> The library is libevs.so.1.0.0.  There are two dynamic links libevs.so.1 and
> libevs.so that point to libevs.so.1.0.0.

That's normal.

> With your suggestion this would put the real binary library libevs.so.1.0.0 and
> one of the links libevs.so.1 into the main package and the link libevs.so into
> the devel.

Yes, that is the normal thing to do. The real library libXYZ.so.a.b.c and the
versioned symlink libXYZ.so.a are usually needed for runtime use, and the
unversioned symlink libXYZ.so is usually only needed at compile/link time.

> But in fact they are all development libraries.

This is what's unusual (i.e. shared libs needed only for development). Is that
really true? If so, it's correct to put the whole lot in the devel package.

> /etc/ld.so.conf.d should be moved and has been.  You are right about the
> scriptlets that call ldconfig.  This was causing a weird bug which I couldn't
> figure out until your suggestion.

The %post devel scriptlet should be:
%post devel -p /sbin/ldconfig
as with the %postun devel scriptlet; this will get rid of an rpmlint warning and
will save you needing:
Requires(post): /sbin/ldconfig
for the devel package.

Youshould also remove /sbin/ldconfig from the Requires(post) for the main
package, since it's no longer required.

This package is now gettimg close to the point where I feel I could approve it
if it was an Extras package. However, this is a review for Core and I'm not sure
whether I, as a non-Red Hat employee, am able to approve Core packages. That may
be a question for Jesse.

-- 
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.