DXR Spec File Review

Upon reviewing the DXR release package spec file made by Alexandros Vlahopoulos and comparing it to the Fedora Packaging Review Guidelines the following are a list of guidelines that have yet to be met or need to be looked at.

• MUST: rpmlint must be run on every package. The output should be posted in the review
  
• MUST: The package must meet the Packaging Guidelines .
  
• MUST: The License field in the package spec file must match the actual license. (Change BSD to GPLv2)
  
• MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. (Find out if theres an architecture it doesnt work on)
  
• MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. (Was there any dependencies?)
  
• MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.(wasnt sure about this one)
  
• MUST: Each package must consistently use macros. ($RPM_BUILD_ROOT, should probably be changed to %{buildroot})
  
• MUST: The package must contain code, or permissable content.
• MUST: All filenames in rpm packages must be valid UTF-8

Below are a list of all the things that SHOULD be looked at or included but are not required.

• SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
  
• SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
  
• SHOULD: The reviewer should test that the package builds in mock.
  
• SHOULD: The package should compile and build into binary rpms on all supported architectures.
  
• SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example.
  
• SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. (once again, if there are any dependencies)
• SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.

This is everything I could find while looking at the DXR-Release spec file, now onto actually auditing it.