Difference between revisions of "Rpm-packaging/ReviewGuidelines"
(→Head) |
(Add workflow for branches and change Head with Groups) |
||
Line 8: | Line 8: | ||
[https://github.com/openstack/renderspec renderspec] - main tool used for transformation from SPEC template into SPEC file. [http://docs.openstack.org/developer/renderspec/ documentaion]<br /> | [https://github.com/openstack/renderspec renderspec] - main tool used for transformation from SPEC template into SPEC file. [http://docs.openstack.org/developer/renderspec/ documentaion]<br /> | ||
+ | =Workflow for branches= | ||
+ | * '''Current work''' | ||
+ | All work must be done in the '''master''' branch of the particular project. | ||
+ | * '''Back-ports/Cherry-picks''' | ||
+ | In case of necessity changes proposed earlier to the '''master''' branch could be cherry-picked into ''stable'' branch. | ||
+ | * '''Cases for back-port/cherry-picks:''' | ||
+ | ** Introduction of a new package if its metadata is valid as for master as for stable | ||
+ | ** There is no difference in amount of run-time and built-time dependencies | ||
+ | ** There is no difference in Version: between ''master'' and ''stable'' | ||
+ | ** There are changes which are fixing %install or %files sections for a particular package | ||
+ | In '''other cases''' updates should be proposed to a particular branch which requires an update! | ||
=Common rules= | =Common rules= |
Revision as of 20:13, 13 April 2016
Contents
Purpose
The main goal to use templates instead of SPEC - flexibility and unification. Templates made in Jinja2 format.
It means that templates made in one way after processing by renderspec tool will fit all supported Linux vendors(SUSE, Fedora, CentOS).
Tool-set
openstack-macros - sub-project which allows to add or substitute required RPM macro used in SPEC template.
pymod2pkg - project used for translation of python source name aka pypi name into Linux package name.
renderspec - main tool used for transformation from SPEC template into SPEC file. documentaion
Workflow for branches
- Current work
All work must be done in the master branch of the particular project.
- Back-ports/Cherry-picks
In case of necessity changes proposed earlier to the master branch could be cherry-picked into stable branch.
- Cases for back-port/cherry-picks:
- Introduction of a new package if its metadata is valid as for master as for stable
- There is no difference in amount of run-time and built-time dependencies
- There is no difference in Version: between master and stable
- There are changes which are fixing %install or %files sections for a particular package
In other cases updates should be proposed to a particular branch which requires an update!
Common rules
Head
- Group:
Setting up proper group for package is a requirement.
- Source0:
Source0 must points to existing tarball location, even if url constructed using macro.
Example:
Group: Development/Libraries Source0: https://pypi.python.org/packages/source/o/%{sname}/%{sname}-%{version}.tar.gz
Documentation
For *-doc package should be specified additional section which describes all meta-data for doc package.
BuildRequires: - populated only with projects required for documentation build.
Please use %bcond_with docs in case of necessity!
Exmaple:
%if %{with docs} %package doc .... %endif %if %{with docs} %files doc ... %endif
Tests
Useful but not mandatory. All directives for unit tests must be set under %check section.
All required for tests projects should be specified as BuildRequires: in the top of template.
Please use %bcond_with test in case of necessity!
Exmaple:
%if %{with test} BuildRequires: required for test projects .... %endif %if %{with test} %check ... %endif
Misc but important!
Under %files section for each package in SPEC template:
- Section %doc should not include: HACKING*, CONTRIBUTING* and AUTHORS
- Section %license should be specified in case of LICENCE file availability in source code