Jump to: navigation, search

Difference between revisions of "Rpm-packaging/ReviewGuidelines"

m (Documentation)
m (Tests)
Line 49: Line 49:
 
All required for tests projects should be specified as '''BuildRequires:''' in the top of template.<br />
 
All required for tests projects should be specified as '''BuildRequires:''' in the top of template.<br />
 
Please use ''%bcond_with test'' in case of necessity!<br />
 
Please use ''%bcond_with test'' in case of necessity!<br />
''Exmaple:''<br />
+
''Example:''<br />
 
  %if %{with test}
 
  %if %{with test}
 
  BuildRequires: required for test projects
 
  BuildRequires: required for test projects
Line 59: Line 59:
 
  ...
 
  ...
 
  %endif
 
  %endif
 +
 
==Misc but important!==
 
==Misc but important!==
 
Under %files section for each package in SPEC template:<br />
 
Under %files section for each package in SPEC template:<br />
 
* Section '''%doc''' should not include: ''HACKING*'', ''CONTRIBUTING*'' and ''AUTHORS''<br />
 
* Section '''%doc''' should not include: ''HACKING*'', ''CONTRIBUTING*'' and ''AUTHORS''<br />
 
* Section '''%license''' should be specified in case of ''LICENCE'' file availability in source code<br />
 
* Section '''%license''' should be specified in case of ''LICENCE'' file availability in source code<br />

Revision as of 13:25, 8 September 2016

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!
Example:

%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!
Example:

%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