Bug 543151 - Review Request: erlang-exmpp - A library for the eXtensible Messaging and Presence Protocol
Review Request: erlang-exmpp - A library for the eXtensible Messaging and Pre...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
NotReady
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-01 14:20 EST by Peter Lemenkov
Modified: 2016-03-07 07:04 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-04 07:05:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Lemenkov 2009-12-01 14:20:38 EST
Spec URL: http://peter.fedorapeople.org/erlang-exmpp.spec
SRPM URL: http://peter.fedorapeople.org/erlang-exmpp-0.9.1-1.fc12.src.rpm
Description: Erlang XMPP library (exmpp) is a fast and scalable library for the eXtensible
Messaging and Presence Protocol.


Koji scratchbuild:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1841907

rpmlint:
[petro@Sulaco SPECS]$ rpmlint ../RPMS/ppc/erlang-exmpp-*
erlang-exmpp.ppc: E: invalid-soname /usr/lib/erlang/lib/exmpp-0.9.1/priv/lib/exmpp_xml_expat_legacy.so exmpp_xml_expat_legacy.so
erlang-exmpp.ppc: E: invalid-soname /usr/lib/erlang/lib/exmpp-0.9.1/priv/lib/exmpp_compress_zlib.so exmpp_compress_zlib.so
erlang-exmpp.ppc: E: invalid-soname /usr/lib/erlang/lib/exmpp-0.9.1/priv/lib/exmpp_xml_expat.so exmpp_xml_expat.so
erlang-exmpp.ppc: E: invalid-soname /usr/lib/erlang/lib/exmpp-0.9.1/priv/lib/exmpp_stringprep.so exmpp_stringprep.so
erlang-exmpp.ppc: E: invalid-soname /usr/lib/erlang/lib/exmpp-0.9.1/priv/lib/exmpp_tls_openssl.so exmpp_tls_openssl.so
2 packages and 0 specfiles checked; 5 errors, 0 warnings.
[petro@Sulaco SPECS]$

These messages can be ignored since they mean that so-name has no suffix (which is normal for erlang C-modules).
Comment 1 Peter Lemenkov 2009-12-07 10:28:42 EST
I discovered a very nasty issue with both 0.9.1 and current svn, which should be fixed before review.

I'll update whiteboard when it will be fixed.
Comment 3 Florent Le Coz 2010-01-13 14:25:35 EST
Some quick notes about your spec file :

your %files section contains many many lines, this is bad for maintenance (if the new version has changes in its documentation for example, you'd have to check each file one by one…)

you could do, for example :

%doc doc/stylesheet.css 
%doc doc/erlang.png
%doc doc/*.html
%{_libdir}/erlang/lib/%{realname}-%{version}

The last line says that your package owns the directory and all its content (and sub-content), no need to specify each file

Also, you should use %global instead of %define (line 1)

Except from that, it's OK for me.
Comment 4 Peter Lemenkov 2010-01-17 05:36:18 EST
(In reply to comment #3)
> Some quick notes about your spec file :
> 
> your %files section contains many many lines, this is bad for maintenance (if
> the new version has changes in its documentation for example, you'd have to
> check each file one by one…)

I obviously didn't generate this list by hand - that would be quite silly :).

In fact, I believe, that such large %files sections does help maintainership, because you know exactly which modules were added or removed at every upgrade (which, in turn, helps quickly resolving issues with potential ABI incompatibilities with other applications).

Although, if you're insisting in simplifying this section, then I'll do this.

> Also, you should use %global instead of %define (line 1)

Good catch, thanks!
Comment 7 Jason Tibbitts 2010-11-24 21:38:21 EST
I see you commented on the invalid-soname rpmlint complaints, and I agree that they seem to be expected for erlang packages.  But what about these:

  erlang-exmpp.x86_64: E: zero-length
   /usr/share/doc/erlang-exmpp-0.9.5/exmpp_xml.html

And the 68 undefined-non-weak-symbol complaints like:

  erlang-exmpp.x86_64: W: undefined-non-weak-symbol
   /usr/lib64/erlang/lib/exmpp-0.9.5/priv/lib/exmpp_stringprep.so driver_alloc

(install the package and run "rpmlint erlang-exmpp" to see those)

Knowing very little about erlang and nothing of how it usually does linkage, I don't know if those are expected or problematic.
Comment 8 Peter Lemenkov 2010-11-29 07:53:34 EST
(In reply to comment #7)
> I see you commented on the invalid-soname rpmlint complaints, and I agree that
> they seem to be expected for erlang packages.  But what about these:
> 
>   erlang-exmpp.x86_64: E: zero-length
>    /usr/share/doc/erlang-exmpp-0.9.5/exmpp_xml.html
> 
> And the 68 undefined-non-weak-symbol complaints like:
> 
>   erlang-exmpp.x86_64: W: undefined-non-weak-symbol
>    /usr/lib64/erlang/lib/exmpp-0.9.5/priv/lib/exmpp_stringprep.so driver_alloc
> 
> (install the package and run "rpmlint erlang-exmpp" to see those)
> 
> Knowing very little about erlang and nothing of how it usually does linkage, I
> don't know if those are expected or problematic.

Thanks for the report - I'll take a look. Unfortunately the API of this package is still the subject to change (the project is still in somewhat immature state) so I would like to postpone it for a few months more.

The next major ejabberd release (3.x.x) will be based on this library, so we definitely need this library in Fedora - that's why I prefer this ticket to remain open.

So I'm raising NotReady flag here, and I'll clean it when it will be ready for release.
Comment 9 Jason Tibbitts 2010-11-29 12:50:12 EST
Just for the record, because the ERPL and OpenSSL licenses are both a bit odd, I asked Fedora legal if there were any compatibility issues between them.  They said that they didn't see anything, so at least that's not a problem.
Comment 10 James Hogarth 2015-12-03 20:32:06 EST
There has not been any comments on this bug in years.

Peter are you still intending to do something with this?

As per policy if there is no response within a week this bug will be closed so that others may file a fresh review if interested.

https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
Comment 11 Peter Lemenkov 2015-12-04 07:05:43 EST
(In reply to James Hogarth from comment #10)
> There has not been any comments on this bug in years.
> 
> Peter are you still intending to do something with this?

I've lost interest in this package. So I'm afraid it's better to close this for now.

Note You need to log in before you can comment on or make changes to this bug.