[Bug 499875] Review Request: libdasm - Library for disassembling x86 code

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=499875


Jason Tibbitts <tibbs at math.uh.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
             Blocks|                            |182235(FE-Legal)
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
               Flag|                            |fedora-review?




--- Comment #3 from Jason Tibbitts <tibbs at math.uh.edu>  2009-07-09 16:05:52 EDT ---
So, no-soname is really the only issue.  This is generally one of those "get
upstream to fix their broken build procedure" kind of things.  You can fix it
by patching in another option to the gcc call, but I'm not really sure that's a
good idea.  This code hasn't changed in five years so I doubt there's any kind
of an issue here.

However, the real issue I see is that this code isn't public domain.  Yes, we
have this from README.txt:

libdasm is public domain software. You can do whatever you like with it.

but then the source files have copyright statements.  I guess spot gets another
FE-Legal ticket; maybe the "whatever you like" clause gives us sufficient
rights.

I would recommend using _includedir instead of /usr/include, just in case. 
You're already doing that in the %files list but not in %install.

Why do you have a separate copy of the unversioned .so file in the -devel
pacakge instead of a symlink?  I guess it doesn't really matter that much but I
can't figure out a reason for it.

* source files match upstream.  sha256sum:
   34d6c17dbb318bf2e21c6a3ae7dcc53d918ce247f1bd422b123d5e41a730a676  
   libdasm-1.5.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
? license field matches the actual license.
? license is open source-compatible.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
   libdasm.so.1.0()(64bit)
   libdasm = 1.5-2.fc12
   libdasm(x86-64) = 1.5-2.fc12
  =
   /sbin/ldconfig

  libdasm-devel-1.5-2.fc12.x86_64.rpm
   libdasm.so()(64bit)
   libdasm-devel = 1.5-2.fc12
   libdasm-devel(x86-64) = 1.5-2.fc12
  =
   libdasm = 1.5-2.fc12

  pydasm-1.5-2.fc12.x86_64.rpm
   pydasm.so()(64bit)
   pydasm = 1.5-2.fc12
   pydasm(x86-64) = 1.5-2.fc12
  =
   libdasm = 1.5-2.fc12
   libpython2.6.so.1.0()(64bit)
   python(abi) = 2.6

* shared libraries are installed:
*  ldconfig is called properly.
X  unversioned .so file is a separate copy and not a link.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files.
* scriptlets OK (ldconfig).
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* header is in the -devel subpackage.
* no static libraries.
* no libtool .la files.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.