Bug 165952

Summary: Review Request: libsx. Simple X library
Product: [Fedora] Fedora Reporter: Patrice Dumas <pertusus>
Component: Package ReviewAssignee: Ed Hill <ed>
Status: CLOSED NEXTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://freshmeat.net/projects/libsx/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-29 21:11:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 163779, 165955    

Description Patrice Dumas 2005-08-15 09:47:43 UTC
SRPM Name or Url: http://www.environnement.ens.fr/docs/fc-srpms/libsx-2.05-2.src.rpm
Description: 

Libsx (the Simple X library) is a library of code that sits on top of and
to the side of the Athena widget set.  Its purpose is to make writing X
applications *much* easier.

Comment 1 Patrice Dumas 2005-08-15 09:51:41 UTC
I cannot reach the upstream source anymore. I think I found it from the
freshmeat page: http://freshmeat.net/projects/libsx/. The spec file was borrowed
from monkey rpms: http://monkeyrpms.net/fc2-i386/html/libsx.html, which has
version 2.04. A diff between the 2.05 included in my srpm and the monkey rpm
2.04 shows very few differences, almost only version strings.

Comment 2 Patrice Dumas 2005-08-15 09:52:11 UTC
It is a grads dependency.

Comment 3 Ed Hill 2005-08-16 03:55:57 UTC
Hi Patrice, Since this is a dependency for GrADS I'll add it to my to-do list.

Comment 4 Ralf Corsepius 2005-08-16 04:42:00 UTC
# rpmlint  /users/packman/src/rpms/RPMS/i386/libsx-2.05-2.i386.rpm
E: libsx invalid-soname /usr/lib/libsx.so libsx.so
E: libsx shlib-with-non-pic-code /usr/lib/libsx.so
W: libsx devel-file-in-non-devel-package /usr/include/libsx.h
W: libsx devel-file-in-non-devel-package /usr/include/freq.h
W: libsx devel-file-in-non-devel-package /usr/lib/libsx.a
W: libsx devel-file-in-non-devel-package /usr/lib/libfreq.a

IMO, in this case, rpmlint is right and all of them should be considered blockers.

Also, freq.h probably is an internal header, which should not be shipped.

Comment 5 Patrice Dumas 2005-08-16 12:15:34 UTC
The freq.h is indeed an internal header and libfreq.a also shouldn't be shipped.
I made a new package that don't ship them anymore. I also added mkinstalldirs to
have it build in mock. And I also added some doc and fixed the old freq example
to have an example of use of GetFile. I fixed the shared libs issues and split
the package in devel and non devel. Here is the rpm changelog entry:

- don't ship freq.h or libfreq.a, it is an example
- add a simpler definition of SimpleGetFile in freq
- ship the example dirs and the doc
- use and ship mkinstalldirs to create the dirs instead of mkdirhier
- handle correctly shared libraries


The new package is at

http://www.environnement.ens.fr/docs/fc-srpms/libsx-2.05-3.src.rpm

Comment 6 Ed Hill 2005-08-17 02:17:12 UTC
Hi Patrice, I tried the -3 version and now rpmlint does not complain 
about the main package (which is good) but it does give 16 
dangling-relative-symlink warnings such as:

  W: libsx-devel dangling-relative-symlink
     /usr/share/doc/libsx-devel-2.05/xmore/libsx.h ../src/libsx.h

and one error:

  E: libsx-devel wrong-script-interpreter
     /usr/share/doc/libsx-devel-2.05/pcurve/makefile "smake"


Comment 7 Patrice Dumas 2005-08-17 07:34:06 UTC
I fixed the dangling symlinks by removing the files. The error seems doubly
wrong to me: the makefile is not executable and smake may be a valid
interpreter. Should I really fix it?

I know that some of the examples won't build as is but I don't think this is
something we should bother with.

Comment 8 Ed Hill 2005-08-25 19:26:41 UTC
Hi Patrice, heres a more thorough review:

needswork:
 - please see rpmlint errors above (comment #6)
 - please use:  Requires: %{name} = %{version}-%{release}
   instead of:  Requires: %{name} = %{version}

good:
 - source matches upstream
 - appears to satisfy all the Guidelines
 - license is OK and included
 - spec looks good
 - builds in mock on FC-4
 - ldconfig looks OK
 - dir ownership OK
 - permissions OK
 - clean OK
 - code not content
 - proper use of -devel sub-package

and, overall, it looks good.  So its APPROVED provided you make the above
(small) changes before requesting the first build.  And I'll review GrADS
next.

Comment 9 Patrice Dumas 2005-08-26 12:09:15 UTC
You are really sure that I should remove the 

#!smake

even if it there is no problem with using smake to rebuild makefiles and the
makefile isn't executable?

I have added for the -devel package:
Requires: xorg-x11-devel



Comment 10 Ed Hill 2005-08-26 13:55:45 UTC
Honestly, I'm not sure.  ;-)

What is "smake", anyway?  I'm not familiar with it and it doesn't seem to be 
included anywhere in Fedora--or is it?

And since it is just an example makefile I suppose it really doesn't matter 
whether you leave it there or not.

Comment 11 Patrice Dumas 2005-08-26 19:39:24 UTC
It is an alternate system with similar goals than automake. And it is not in
fedora (but in debian). But the point is not there, whatever smake is, having a 

#! smake

at the first line of a non executable makefile is not a packaging error in my
opinion. 

I import the package in the cvs with that rpmlint error.