https://bugzilla.redhat.com/show_bug.cgi?id=658754 --- Comment #10 from Cristian Ciupitu <cristian.ciupitu@xxxxxxxxx> --- 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_variables [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/f17;hb=f17. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review