Nov 7, 2012

Updates to openSUSE Packaging Guidelines

On the opensuse-packaging mailing list, we've recently formed a team that will take care of the packaging guidelines and introduced a small process to change them.

As part of that process, we're announcing regularly the changes to the packaging guidelines. Since this is a first such announcement, it is not a complete change but just points out a few things from the past few months. In the future, we will send out this email once a month.

The Packaging guidelines can be found in the openSUSE wiki at

The list of changes that I'd like to mention are:
  • New Lua Guidelines
  • Reworked font guidelines
  • Documenting changes in packages
  • Teams involved

New Lua Guidelines

We now have guidelines for lua at

Reworked font guidelines

The packaging of fonts has been completely changed, and is documented at

Documenting changes in packages

The openSUSE review team is now also enforcing proper documenting
changes in packages:

First, the .changes entry (rpm changelog) surves two purposes:
  • News for the user
  • History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixes).

Information about updates

A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed.
Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will.

Documenting patch life cycle

The rules about patches are listed at .

Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed).

The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the openSUSE Factory Review team:

The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that...
Note: The review team is not enforcing the usage of patch markup unless the package already follows this convention.

Teams involved, contact

I mentioned two teams previously, these are the openSUSE review team
and the team taking care of the guidelines. You can reach both via the opensuse-packaging mailing list.