Updated package:

Spec URL: http://www.ocjtech.us/ejabberd-1.1.1-2.spec
SRPM URL: http://www.ocjtech.us/ejabberd-1.1.1-2.src.rpm

%changelog
* Wed May 24 2006 Jeffrey C. Ollie <jeff> - 1.1.1-2
- Munge Makefile.in a bit more...
- Change ownership/permissions - not *everything* needs to be owned by ejabberd

Just took a quick look at this and I'm having trouble figuring out these rpmlint
complaints:

W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/iconv_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/stringprep_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/ejabberd_zlib_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/tls_drv.so

"rpmlint -i" is no help, but inspecting the rpmlint source shows that it's
calling objdump --headers --private-headers and grepping for "SONAME".  Indeed,
those libraries don't show one.

Unfortuantely I've no idea how problematic this is or how you'd go about fixing it.

(In reply to comment #2)
> Just took a quick look at this and I'm having trouble figuring out these rpmlint
> complaints:
> 
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/iconv_erl.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/stringprep_drv.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/ejabberd_zlib_drv.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/tls_drv.so
> 
> [...]
> 
> Unfortuantely I've no idea how problematic this is or how you'd go about
fixing it.

I don't think that its a problem... the libraries aren't general purpose shared
libraries but are dynamically loaded modules pulled in by the Erlang runtime. 
They are similar to Python or Perl modules coded in C rather than Python/Perl.
They are versioned by the %{_libdir}/ejabberd-1.1.1 directory so different
versions of ejabberd shouldn't load the wrong modules.  It seemes to work - I
have personally set up three servers using these ejabberd RPMs.

I'm sure the program works; the question is whether the package meets the Extras
guidelines and one of those is that rpmlint must have no valid complaints. 
Unfortunately I'm not familiar with this particular complaint since I've not
seen it before.  I understand that these are modules pilled in by Erlang, but
neither Perl nor Python will generate libraries without SONAME as far as I know.
 I've reviewed other Erlang packages (c.f. wings) which did not have this problem.

I received little guidance on IRC; just a comment that this looks like an
upstream bug.  I'll try on extras-list.

(In reply to comment #4)
> I'm sure the program works; the question is whether the package meets the Extras
> guidelines and one of those is that rpmlint must have no valid complaints. 
There are packages that include .so files without SONAME, e.g.,
R
elfutils
gcj compiled jar packages
...
This is not a problem as long as they are not public libraries in /usr/lib.
However it is probably easy to fix in the Makefile by adding
-Wl,-soname,expat_erl.so for example to the link command.

Adding back some lost comments:

------- Additional Comments From jeff.ia.us  2006-06-08 22:06 EST
-------
(In reply to comment #5)

> This is not a problem as long as they are not public libraries in /usr/lib.
> However it is probably easy to fix in the Makefile by adding
> -Wl,-soname,expat_erl.so for example to the link command.

I tried adding the "-Wl,-soname,expat_erl.so" to the link command, now all I get
are errors like this from rpmlint:

E: ejabberd invalid-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
expat_erl.so

where before I was merely getting warnings.  Unless someone can show a
functional problem I'd prefer to ignore those warnings and move on.

------- Additional Comments From gemi  2006-06-09 03:09 EST -------
(In reply to comment #6)
> (In reply to comment #5)
> are errors like this from rpmlint:
> 
> E: ejabberd invalid-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
> expat_erl.so
> 
> where before I was merely getting warnings.  Unless someone can show a
> functional problem I'd prefer to ignore those warnings and move on.

Indeed rpmlint wants the soname to be of the form lib<libname>.so.<major>.
I also think that this isn't worth the trouble and should be ignored.

I took another look at this and after looking over other packages I agree with
Gerard that the no-soname warning is acceptable for libraries that don't live
immediately in %{_libdir}.

Full review forthcoming.

I ended up having to redo my mock setup last night, but everything's working
fine today.  The package builds fine on x86_64, development.  Here's what
rpmlint has to say:

W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/iconv_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/stringprep_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/ejabberd_zlib_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/tls_drv.so
I'll accept these as meaningless for private internal libraries.

E: ejabberd non-standard-uid /var/log/ejabberd ejabberd
E: ejabberd non-standard-uid /etc/ejabberd/ejabberd.cfg ejabberd
E: ejabberd non-standard-uid /etc/ejabberd ejabberd
E: ejabberd non-standard-uid /var/lib/ejabberd/spool ejabberd
E: ejabberd non-standard-uid /etc/ejabberd/inetrc ejabberd
E: ejabberd non-standard-uid /var/lib/ejabberd ejabberd
E: ejabberd non-standard-gid /var/log/ejabberd ejabberd
E: ejabberd non-standard-gid /etc/ejabberd/ejabberd.cfg ejabberd
E: ejabberd non-standard-gid /etc/ejabberd ejabberd
E: ejabberd non-standard-gid /var/lib/ejabberd/spool ejabberd
E: ejabberd non-standard-gid /etc/ejabberd/inetrc ejabberd
E: ejabberd non-standard-gid /var/lib/ejabberd ejabberd
Expected given that the daemon runs with its own uid/gid.

E: ejabberd non-standard-dir-perm /var/log/ejabberd 0750
E: ejabberd non-standard-dir-perm /etc/ejabberd 0750
E: ejabberd non-standard-dir-perm /var/lib/ejabberd/spool 0750
E: ejabberd non-standard-dir-perm /var/lib/ejabberd 0750
E: ejabberd non-readable /etc/ejabberd/ejabberd.cfg 0640
E: ejabberd non-readable /etc/ejabberd/inetrc 0640
Permissions limited for security reasons.

W: ejabberd non-conffile-in-etc /etc/logrotate.d/ejabberd
You should mark this as %config in your %files list.  This is the only rpmlint
issue that I see.

Nothing seems to own /usr/lib64/ejabberd-1.1.1.  This package should own it.

The documentation is about half of the total size of the package.  Would you
consider splitting the html, pdf and image files off into a separate -doc
subpackage?

Review:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text included in package.
* source files match upstream:
   ef6fae4a3f9c7f807f21e9cd3dae195b  ejabberd-1.1.1.tar.gz
* latest version is being packaged.
* BuildRequires are proper.
* package builds in mock (development, x86_64).
X rpmlint has many ignorable complaints and one blocker.
* final provides and requires are sane:
   config(ejabberd) = 1.1.1-2.fc6
   ejabberd_zlib_drv.so()(64bit)
   expat_erl.so()(64bit)
   iconv_erl.so()(64bit)
   stringprep_drv.so()(64bit)
   tls_drv.so()(64bit)
   ejabberd = 1.1.1-2.fc6
  =
   /bin/bash
   /bin/sh
   /sbin/chkconfig
   /sbin/service
   config(ejabberd) = 1.1.1-2.fc6
   erlang
   fedora-usermgmt
   libcrypto.so.6()(64bit)
   libexpat.so.0()(64bit)
   libssl.so.6()(64bit)
   libz.so.1()(64bit)
* shared libraries are present, but internal to ejabberd.
* package is not relocatable.
X owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is not present; no test suite upstream.
* scriptlets present and OK (user creation, service installation and shutdown)
* code, not content.
X documentation not is small.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

Updated Spec/SRPM that should fix the above blockers:

http://repo.ocjtech.us/misc/fedora/5/SRPMS/ejabberd-1.1.1-6.fc5.spec
http://repo.ocjtech.us/misc/fedora/5/SRPMS/ejabberd-1.1.1-6.fc5.src.rpm

Oops... forgot to remove a patch that i was testing with:

http://repo.ocjtech.us/misc/fedora/5/SRPMS/ejabberd-1.1.1-7.fc5.spec
http://repo.ocjtech.us/misc/fedora/5/SRPMS/ejabberd-1.1.1-7.fc5.src.rpm

Looks like the three issues I had are fixed:

logrotate.d file marked %config.
owns %{_libdir}/ejabberd-1.1.1
-doc package split off.

APPROVED

Thanks for the review!  Package imported and built!  FC-4 and FC-5 branches
requested.

Package Change Request
======================
Package Name: ejabberd
New Branches: EL-5
Updated EPEL Owners: jcollie,silfreed

Package Change Request
======================
Package Name: ejabberd
New Branches: EL-5
Updated EPEL Owners: jcollie,silfreed


Argh, forgot to change the flag...

cvs done.

Package Change Request
======================
Package Name: ejabberd
InitialCC: erlang-sig

Done.