I’ve added a new package (grub2) to the openSUSE distribution and like to share with you what needs to be done for it, I’m using the package “grub2” as example. To get a package in the distribution, it needs to be in the openSUSE:Factory project in the openSUSE Build Service.
- Get an openSUSE Build Service account. It’s free, just go to the Build Service and register.
- Go to your “Home Project” and follow the link to “add a new package”, I use “grub2” as package and filled in the details.
- Now add all the files you need to properly build the package. For openSUSE Factory, you need the spec file (grub2.spec), an empty changes file (grub2.changes) and all source files.
- Some of the next steps are done best by the openSUSE Build Service command line client osc, so you should install the current version on your system. If you’re running openSUSE, just do a “zypper in osc”, if you use another distribution, download it from the “openSUSE:Tools” project for your distribution (best way to find it search via our search interface for osc).
- I propose to check out the files with osc, e.g. “osc co home:a_jaeger grub2”.
- Use “osc vc” to add entries to the new changes file describing what you have changed in the package.
- Go to your “Home Project” in the web user interface and add “openSUSE Factory” using “Add Repository” as build target.
- Build the package locally using “osc build”. If it succeeds, submit all fixes with “osc ci” to the build service.
- Now it’s time to wait until the build succeeds on all platforms and distributions you have enabled – and if not to fix it until it succeeds.
- Tell the openSUSE Factory maintainers about the new package in an email to the opensuse-factory list with all details as explained here and discuss which devel package should be used for it.
Note that all packages in openSUSE:Factory are developed in so called “devel projects”. So, decide where your package fits best – or add it to “devel:openSUSE:Factory”. I choose the later. - Submit the package to the devel project with “osc sr <your-home-project> <packagename> <devel-project>” and add a nice comment (in my case “osc sr home:a_jaeger grub2 devel:openSUSE:Factory”).
- Once the submitrequest gets accepted, check that you are setup as maintainer for the package with “osc maintainer devel:openSUSE:Factory grub2”, if you are the maintainer, you have write and review access to the package.
- Submit the package from the devel project to openSUSE:Factory using osc. I did a “osc sr devel:openSUSE:Factory grub2 openSUSE:Factory”.
Since the package gets submitted the first time, it will go through a good first review including a license check. So, give the team a week or two for the review. Eventually you’ll get noticed about the check in. - Now you can update the package in the devel project at your own consideration and don’t forget to submit it timely again after testing to openSUSE:Factory so that people running Factory can use it.
I advise to read the documentation about Factory to understand the mentioned concepts and not just blindly follow my cook book.
Keep in mind that having packages in openSUSE is an honor and an obligation. An openSUSE release gets fixes for 18 months and as a maintainer of the package, it’s expected that you take care of the package. With having it in Factory, please remember to update it in time for a release and keep in mind that we’re not doing any major updates in a released distribution.
Both comments and pings are currently closed.
It is unclear for me what the spec file (grub2.spec) and the changes file (grub2.changes) are and how can be generated.
Once a package submitted in factory, how it could be moved to the standard distribution ? (in the stable repos)
The grub2.spec file if the file that contains the information about how the package is built. See http://www.rpm.org/max-rpm/ch-rpm-inside.html for more information about spec files. The build tutorial (http://en.opensuse.org/SUSE_build_tutorial) is also very helpful.
The grub2.changes file is just a file to keep track of changes. Rather than changing the spec file for every update or change we keep track of these changes in the .changes file. You can consider this file to be a history of your more verbose check-in comments.