[Bug 993324] Review Request: ell - Embedded LL library

[bugzilla at redhat.com]

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



--- Comment #1 from Michael Schwendt <bugs.michael at gmx.net> ---
> extra care when reviewing its SPEC file

Not really.  Header-only C/C++ APIs aren't so special. It's just that there
isn't much in the packaging guidelines. Also, there have been package
submissions that named the src.rpm "something-devel" because there would be no
base package to build.
There are more packaging pitfalls with normal lib+header APIs (e.g. sometimes
there are headers with a missing lib, or a lib gets deleted after building it,
or private headers get installed accidentally and packaged).


> Version:        0.0.0
> Release:        20130617svn

That's not one of Fedora's package versioning schemes yet:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning

Why the triple '0'? Why not a single '0'?

And for snapshots, you'll need the pre-release prefix (for much more
flexibility):
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

  Release:        0.1.20130617svn


> Summary:        Embedded LL library

Sum up what it does, not what it's named. The %description is short enough to
be suitable as a %summary. Example:

  Summary: Header-only C++ library to write EBNF grammars

https://fedoraproject.org/wiki/Examples_of_good_package_summaries
(not perfect but a good start)


> License:        LGPLv3

The source files say "or later" -> LGPLv3+

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#.22or_later_version.22_licenses


> %build
> make %{?_smp_mflags}

Since this builds only the test-suite, this "make" invocation could/should be
moved into the %check section.

It doesn't use Fedora's compiler flags, btw:
https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags


> # to track the usage of this library
> Provides:       %{name}-static = %{version}-%{release}

Yes, that is not in the guidelines and only helps with tracking (via scripts or
repoquery). Basically, any other package can "BuildRequires: ell-devel" and
build successfully without any need to make use of to the ell-static Provides.
It's the responsibility of the package maintainer(s) to know when to rebuild
dependencies against important ELL updates.


> Processing files: ell-devel-0.0.0-20130617svn.x86_64

It would be interesting to mention in the spec file that this package does not
set "BuildArch: noarch". I assume that is done, so the test-suite will be run
for all target archs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=H2RxFTJDYR&a=cc_unsubscribe