[Bug 596461] Review Request: lzma-sdk - SDK for lzma compression

[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=596461

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
               Flag|                            |fedora-review?

--- Comment #39 from Jason Tibbitts <tibbs at math.uh.edu> 2011-01-27 14:09:51 EST ---
As much as I think this kind of thing is distasteful, I can't think of a better
way to avoid the bundling issue while still allowing upx in the distribution. 
Not that I really see the point of upx, but that's not up to me.

Not sure if this submission is sufficiently old that it predates the new
unnecessity of buildroot, but just to be sure: if you don't want to build this
for el4 or el5, you can remove BuildRoot:, %clean and the first line of
%install.

Is there any file in this package that should remain executable?  If not,
perhaps simply all of the find calls with just
  find . -type f -exec chmod -x {} \;
or whatever your preferred variant is?

And while I'm in %prep:
Why not use %setup -c instead of doing everything manually?  Seems that would
simply things a good bit.

There are a few line endings that need encoding:
  lzma-sdk.noarch: W: wrong-file-end-of-line-encoding
   /usr/share/doc/lzma-sdk-4.6.5/7zFormat.txt
   /usr/share/doc/lzma-sdk-4.6.5/7zC.txt
   /usr/share/doc/lzma-sdk-4.6.5/history.txt
   /usr/share/doc/lzma-sdk-4.6.5/lzma.txt
   /usr/share/doc/lzma-sdk-4.6.5/Methods.txt
   /usr/share/doc/lzma-sdk-4.6.5/7zFormat.txt
   /usr/share/doc/lzma-sdk-4.6.5/7zC.txt
   /usr/share/doc/lzma-sdk-4.6.5/history.txt
   /usr/share/doc/lzma-sdk-4.6.5/lzma.txt
   /usr/share/doc/lzma-sdk-4.6.5/Methods.txt

I really hate thinking about this kind of thing, but any time you see "Public
Domain" you have to worry.  I've asked the legal list if this is properly
public domain.

I think the perl(SevenZip) provide is bogus.  I can't imagine where it's coming
from, unless rpm is on enough crack to parse
  package SevenZip;
out of Java/SevenZip/CRC.java or Java/SevenZip/LzmaAlone.java.  Actually, I
think that is where it comes from.  Needs to be filtered in any case.

* source files match upstream.  sha256sum:
  c935fd04dd8e0e8c688a3078f3675d699679a90be81c12686837e0880aa0fa1e
   lzma465.tar.bz2
* 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.
? license field matches the actual license.
* BuildRequires are proper (none).
* package builds in mock (rawhide, x86_64).
* package installs properly.
X rpmlint has valid complaints.
X final provides and requires:
X  perl(SevenZip)  
   lzma-sdk = 4.6.5-1.fc15
  =
   (no requires)

* no bundled libraries.
* 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.

-- 
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.