Bug 630681

You hadn't run rpmlint.
If you did, you would find:

>lasem-tools.x86_64: W: non-standard-group System environment/Libraries

Must be: "System Environment/Libraries"

>lasem.x86_64: W: shared-lib-calls-exit /usr/lib64/liblasem-0.4.so.3.0.0 exit.5

It says by itself, needs to be fixed.

>lasem-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/lasemrender ['/usr/lib64']

Look at https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

Source0 URL had changed to http://ftp.gnome.org/pub/GNOME/sources/lasem/0.3/%{name}-%{version}.tar.bz2 .

>lasem-tools.x86_64: W: no-manual-page-for-binary lasemrender

Try to follow https://fedoraproject.org/wiki/Packaging:Guidelines#Man_pages, if possible.

On the second sight, itex2mml seems to be stand-along project. On http://golem.ph.utexas.edu/~distler/blog/itex2MML.html there is a new version of it available. According to https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries itex2MML needs to be packaged separately, and lasem - patched to force usage of it.

(In reply to comment #1)
> >lasem.x86_64: W: shared-lib-calls-exit /usr/lib64/liblasem-0.4.so.3.0.0 exit.5
> 
> It says by itself, needs to be fixed.
> 

$ rpmlint -I shared-lib-calls-exit
shared-lib-calls-exit:
This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the
error, reporting it to the user, closing files properly, and cleaning up any
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the
situation.

--

My take - while upstream should be contacted and exit() probably should be removed, this is not a blocker.

> >lasem-tools.x86_64: W: no-manual-page-for-binary lasemrender
> 
> Try to follow https://fedoraproject.org/wiki/Packaging:Guidelines#Man_pages, if
> possible.

Same here.

As for me, itex2MML is a blocker. If Owen Taylor have a trouble with it, I of cause will try to resolve this issue by myself.

>while upstream should be contacted and exit() probably should be
removed, this is not a blocker.

Any examples of other package? If so, I agree - it is not a blocker.

>Same here.

Sure. No man page is not a blocker, it is what I mean by phrase "if possible".

(In reply to comment #4)
> As for me, itex2MML is a blocker. 

Definitely.

> >while upstream should be contacted and exit() probably should be
> removed, this is not a blocker.
> 
> Any examples of other package? If so, I agree - it is not a blocker.

hdf5, which I maintain :), and netcdf.  Historical reasons at this point, and in at least one case it is called only in rare, specific cases, not as part of general use.

>Historical reasons at this point, and in at least one case it is called only in rare, specific cases, not as part of general use.

I want to know upstream position on this question still. If it will be silence (for a rational amount of time) or willing to leave all as it is, it will be not a blocker.

Just to say that if someone else is interested in this package and wants to take it over, that would be fine with me. Dealing with this isn't very high on my radar at the moment and it could easily be 6 months until I get back to this.

In terms of the notes above:

 * Fixing the rpath would be good. Weird that it ended up with one.... thought the build setup was pretty standard.
 * The 'library calls exit' stuff is just a pet-peeve of the rpmlint maintainer or something. I don't consider it to have any relevance to Fedora packaging. Haven't particularly evaluated the details for this package, but in every previous places I've encountered it, patching out the call would be a very odd thing to do in a Fedora package, and would often make the Fedora library incompatible with the upstream library.
 * I think man pages are only interesting if you write a real useful one and send it upstream. While that is never a bad thing to do, I consider it pretty much independent from the packaging process.
 * Haven't looked into itex2mml ... if it's something that can be packaged separately, sounds reasonable.

I went throught the sources and I drop the "exit" issue. This call is in itex2mml code.

Closing per #7 and time passed from this comment.