Contrib/Adding new packages

From openSUSE

This article describes the process of adding new packages to the Contrib repository.

Maintainer's tasks

Maintainer in this text refers to anyone willing to maintain a package in the openSUSE:Factory:Contrib repository.

• If the package doesn't exist yet, create it in your home project, a subproject thereof or wherever you wish. This project should have a repository based on openSUSE:Factory:Contrib/standard, like this (the name of the repository is not important):

$ osc meta prj <your project>
...
  <repository name="openSUSE_Factory">
    <path repository="standard" project="openSUSE:Factory:Contrib"/>
    <arch>i586</arch>
    <arch>x86_64</arch>
  </repository>
...

If the package requires additional packages from your project, you need to request their inclusion as well.

• The package should follow the SUSE Package Conventions, it has to build on both ix86 and x86_64 and you should test it at least on one of the architectures. During the Milestones phase of Factory, it is OK if you test the package on the latest openSUSE release only, but you should install a development version at some point of time and test your Contrib packages there. You should be prepared to fix build errors, which sometimes occur due to changes in Factory (this is especially true for Kernel Module Packages). See also Contrib#Rules for inclusion of packages in Contrib for further restrictions and requirements.
• Loadable Kernel Modules (LKMs) must be tested on both architectures (x86 + x86-64).
• If you think your package is ready, send an email to the opensuse-contrib mailing list, requesting inclusion of your package. Please include the following in your request:
  • In which project in the buildservice does the package live
  • A brief description of the package
  • How actively is the package developed upstream
  • The amount of testing so far
  • If the package requires additional packages not yet in the Contrib repository.
  • Whatever else you think is important

Example of a review request

• If the package is migrating from Factory into Contrib, then the only requirement is that it must still work. Only very basic testing is required.

Reviewers' Tasks

Check

• If the package adheres to the SUSE Package Conventions
  • Apply common sense here, don't reject a package just because it has a patch with the suffix .diff, but a Foo::Bar perl module should really be named perl-Foo-Bar and not FooBar.
• For common packaging errors, like header files and static libraries in the main package, insufficient / excessive Requires: lines, suspicious %pre/%post scriptlets, etc.
• If the package is distributable via the Build Service at all (refer to the Application Black List) and has an opensource license.
• If the package is actively maintained upstream. Exception to this rule are packages with little or no security risk, but the package maintainer should be able to keep the package working in openSUSE in such cases.

If you think the package is OK, say so. If there is consensus among the reviewers, the package is accepted. If there are objections from any of the reviewers, these should be clarified first (as a last resort, the reviewers vote whether to take the package or not). NOTE: Reviewers should push their and their friends' packages through the same process and they should get an ack from another reviewer. This helps maintaining credibility and transparency.

If a package is accepted, one of the reviewers creates a package in openSUSE:Factory:Contrib with the following in the metadata

$ osc meta pkg openSUSE:Factory:Contrib <package>
...
  <devel project="<where is the package maintained>"/>
  <person role="bugowner" userid="<and by whom>"/>
...

and with a _link to the source package. The maintainer will still maintain the package in his project and the link will make sure that the changes are propagated to Contrib.

Possible improvements

• A staging repository [1]