[Bug 658754] Review Request: CUBRID - a very fast and reliable open source SQL database server.

[Red Hat Bugzilla]

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

--- Comment #10 from Cristian Ciupitu  ---
Verba volant, scripta manent, so I'll write here some of the ideas we talked
about on #fedora-devel.

If the SPEC is changed, the %changelog should be updated and the release
incremented, so that it's easier to determine that everybody has the right
(latest) SPEC file. If the source code is changed, its URL should be changed,
so that people would know if they have the right (latest) source code. And of
course the version, release and Source0 fields of the SPEC need to be updated.
As far as I know the release can be reset to 1, there's no need to increment
it, too.

Since you're planning to support both Fedora 16 and 17 and there are
differences between those systems, you can either propose two SPEC files or one
SPEC file with conditionals in it. The SPEC file will ultimately be stored in a
git repository with a branch for each Fedora version. In my humble opinion
conditionals are recommended because there aren't many differences, but it's
your choice.

The SysV scripts should be replaced with systemd units because that's the
future[1]. Though you might want to keep them for EPEL (Enterprise Linux),
because EL6 does not have systemd yet. If you use conditionals, you can package
systemd units in Fedora>=16 and SysV scripts otherwise.

Regarding the extra functionality of your SysV script like creating a database
or user, I would recommend putting it in another program, for example
cubridadm. Then the user could run cubridadm createuser apache or cubridadm
createdb website. If it's too much for a single program, you could split it
like git into %{_libexecdir}/%{name}/cubridadm-createuser,
%{_libexecdir}/%{name}/cubridadm-createdb and so on, then run these from
cubridadm.

Regarding the strip commands from the SPEC, if they're really needed to prevent
rpmlint warnings (or errors) add a comment specifying so.

Replace %{libdir} with the standard %{_libdir} macro [2]. Your location does
not depend on the architecture (32 or 64 bit) even if you're storing there
binaries.

Don't start the program after installation [3].

If possible, use a private /tmp in your systemd service unit [4].

P.S. You could inspire from PostgreSQL [5].

[1] http://fedoraproject.org/wiki/Features/SysVtoSystemd

[2]
http://fedoraproject.org/wiki/Packaging:RPMMacros#Macros_mimicking_autoconf_...

[3] http://fedoraproject.org/wiki/Packaging:Systemd#Why_don.27t_we....

[4] http://fedoraproject.org/wiki/Features/ServicesPrivateTmp

[5]
http://pkgs.fedoraproject.org/gitweb/?p=postgresql.git;a=tree;h=refs/heads/f....