Ga naar: navigatie, zoeken

Contrib: de universele openSUSE installatiebron voor pakketten van derden


Visie of wat we willen

Dit artikel is nog maar gedeeltelijk vertaald. Als u mee wilt helpen met vertalen lees dan Wiki vertalen naar het Nederlands.

Current model of third-party packages in the Build Service is complicated to use. There are lots of packages across hundreds of Build Service projects, which brings a few problems: repositories are not easy to navigate; there are duplicate packages; repositories are not tested for compatibility with other repositories. The real solution would be to get all packages into Factory.

The goal is to have a universal repository for third-party packages. This repository is viewed as a community-driven extension of Factory, with all it's standards and limitations applied.

Rules or what do we do

In general Contrib has the same rules as Factory, like the release deadlines etc.

Rules for the repository

  • Everything is built against the openSUSE base or packages from this repository
  • No duplication of packages from Factory
  • The repository is branched at openSUSE release time (openSUSE:Factory:Contrib -> openSUSE:<version>:Contrib)
    • After the branch no version updates are allowed anymore, unless explicitly allowed by openSUSE:<version>:Contrib maintainers.
    • Bugfixes happen as patches to the packages

Rules for the packages

  • Packages have to have a package maintainer that cares for:
    • Package Updates
    • Maintenance for packages (fixing bugs, working with upstream on bugs, etc.)
    • Security Updates (SuSE Security Team will help with that)
    • Beta Testing during the openSUSE beta phase
  • Packages need to go through the contrib review process
  • no (file) conflicts with Factory packages

Permissions or who does what

To ensure that we follow the above stated rules we need to have a set of permissions for the repository and the packages in it. Therefore we need 2 roles involved. The maintainer who is responsible for one or more packages and the reviewers who are responsible for the repository itself.


  • Repository is owned by reviewers
    • Submission of new packages happens trough osc submitreq and goes trough an initial review.
    • Repo bugowner is
  • Packages are owned by maintainers
    • Development on packages just happens, no additional review.
    • Package bugowner is the maintainer


  • Repository is owned by reviewers
    • No new packages
  • Packages are owned by reviewers
    • Everything is handled by osc submitreq and goes trough a review
    • Package bugowner is the maintainer

Processes or how do we do it

There's also an alternative approach: osc-contrib command.

New packages to openSUSE:Factory:Contrib

  • Joe Packager wants to maintain the package foo in the Contrib repository
  • Joe Packager creates the package in his home repository (or any other repository he has write access too)
  • Joe Packager try to build the package towards Contrib to check, that there are not some missing dependencies, or private setting in prjconf.
osc build --debug --alternative-project openSUSE:Factory:Contrib standard [<arch>]
  • After Joe Packager thinks his package is in a good enough shape he sends a submitrequest to the Contrib repository with osc

 $ osc submitreq own-project package-name openSUSE:Factory:Contrib package-name -m "add package-name"

  • A mail gets send to and Joe Packager gets the following answer:
But this address is not subscribed, and only subscribers may post to the list.

This does not mean that submission failed, which can be verified at the Contrib requests page. You will not get a personal notification if your submission is rejected; the rejection note will appear only on the mailing list.

  • The Contrib reviewer either accepts the submission

 $ osc request accept 6001 --message="reviewed ok. You are now maintainer of foo in Contrib"

or declines it

 $ osc request decline 6001 --message="Sorry. Declined. Fix the Factory build errors first. If you need help lets talk on opensuse-contrib :)"

  • As last step the reviewer sets the original sumitter as maintainer and bugowner for the package

 $ osc meta pkg -e openSUSE:Factory:Contrib blackbox
 <person userid="jpack" role="maintainer"/>
 <person userid="jpack" role="bugowner"/>

  • If the accepted package is included in one of the distributions we are building Contrib for (11.1 and 11.2 ATM), the reviewer disables building of this package for such distributions. This is the case of packages that were moved from Factory to Contrib or the other way round.

 # cgdb was moved from Factory to Contrib between 11.1 and 11.2
 $ osc meta pkg -e openSUSE:Factory:Contrib cgdb
   <disable repository='openSUSE_11.1'/>

Bugfixes for packages in openSUSE:Factory:Contrib

  • Joe Packager checks out the package from openSUSE:Factory:Contrib

 $ osc co openSUSE:Factory:Contrib blackbox

  • Joe Packagers does his changes and checks the package back in

 $ osc ci -m 'fixed bug in init script'

Bugfixes for packages in openSUSE:<version>:Contrib

  • Joe Packager branches the package from openSUSE:<version>:Contrib

 $ osc branch openSUSE:11.1:Contrib blackbox

  • Joe Packager can now check out the package from his branch area and work on the package

 $ osc co home:jpack:branches:openSUSE:11.1:Contrib/blackbox

  • Once Joe Packager thinks that he has fixed the issue he submits the package

 $ osc ci -m "fixed serious bug"

  • after everything is building Joe creates a submitrequest for openSUSE:<version>:Contrib again

 $ osc sr create -m 'fixed serious bug'

 $ osc submitreq accept 6002 --message="reviewed ok. Update is released"

or declines it

 $ osc submitreq decline 6002 --message="Sorry. Declined. There is another buffer overflow in main.c line 155"

Similar procedure is used also if Joe Packager wants to modify a package in openSUSE:Factory:Contrib, but if he does not have maintainer permissions for this package (it is maintained by somebody else). The submitrequest should be handled by the package maintainer.

Security bugs for packages in openSUSE:<version>:Contrib

  • The same as above only that the bugreporter will be the security team.

Mailing list or whom to talk to

  • - Mailing list for openSUSE Contrib repository
Inschrijven | Uitschrijven | Help | Archieven

See the mailing lists page to learn how to subscribe and how to handle openSUSE mainling lists in general

Frequently asked questions

  • Q: Do we want to have a contrib-(staging|beta|unstable|experimental|testing) repository where packages have to undergo some reported tests before they end up in contrib ?
  • A: Generally I prefer to keep unstable/experimental stuff either upstream or in user's OBS, not in contrib. After package becomes stable, request for integration can be sent.
  • Q: Please define the release cycle (freezing, announcing, etc...)
  • A: "Contrib" will be in sync with Factory release cycles. It will develop during openSUSE Milestone cycle during openSUSE development cycle, together with it. Freezing of Factory will also affect "Contrib".
  • Q: How to add the Factory:Contrib repository in to my openSUSE ?
  • A: For openSUSE 11.1 use:
     zypper ar -f openSUSE:Factory:Contrib:openSUSE_11.1 
  • A: For openSUSE 11.2 use:
     zypper ar -f openSUSE:Factory:Contrib:openSUSE_11.2 
  • A: For openSUSE 11.3 use:
     zypper ar -f openSUSE:Factory:Contrib:openSUSE_11.3 
  • A: For openSUSE Factory use:
     zypper ar -f openSUSE:Factory:Contrib 
  • Q: How to add the openSUSE:11.2:Contrib repository to my openSUSE ?
  • A: Use:
     zypper ar 

or use yast2->Software Repositories->Add->select Community Repositories->Next->select Contrib->OK.

  • Q: But I don't like a Factory, it's so much updates. Aren't here a backports?
  • A: Yes, the Contrib is built for openSUSE 11.1, because we want to allow an easier adoption and testing of Contrib. But consider Factory (11.2) is a main target, so this is not a "backport", just other build target.