Bug 165952 - Review Request: libsx. Simple X library
Review Request: libsx. Simple X library
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ed Hill
David Lawrence
http://freshmeat.net/projects/libsx/
:
Depends On:
Blocks: FE-ACCEPT 165955
  Show dependency treegraph
 
Reported: 2005-08-15 05:47 EDT by Patrice Dumas
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-29 17:11:29 EDT
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 Patrice Dumas 2005-08-15 05:47:43 EDT
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 05:51:41 EDT
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 05:52:11 EDT
It is a grads dependency.
Comment 3 Ed Hill 2005-08-15 23:55:57 EDT
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 00:42:00 EDT
# 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 08:15:34 EDT
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-16 22:17:12 EDT
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 03:34:06 EDT
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 15:26:41 EDT
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 08:09:15 EDT
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 09:55:45 EDT
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 15:39:24 EDT
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.


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