How to become a packager
|How to become a packager|
This article will help you understand how to become a packager, from creating source packages for the CCR to using the build system to build binary packages.
There are different packager ranks in the Chakra community, which define your rights and responsibilities. Once you know how to create a package, you can become a CCR Packager right away. Just remember: with great power comes great responsibility.
CCR Packagers upload source packages to the Chakra Community Repository.
To become a packager, first you need to know how to create a package. It's a rather simple process, which any person should be able to follow. With practice, it may become completely trivial to you. Some packages may be tricky, but you can always ask in the IRC or in the Forum.
Any person can register an account in the Chakra Community Repository. That will grant her or him permission to upload source packages to that repository. Once uploaded, a source package can be downloaded, extracted, packaged and installed by any Chakra user. It is also possible to manage source packages with ccr, a helper that follows nearly the same syntax as pacman, but it can also search and use the CCR.
- Upload source packages to the Chakra Community Repository.
- Follow the packaging standards.
- Before uploading a new source package to the Chakra Community Repository, ensure that it isn't already available in the official repositories. You can upload development (package-dev) and unstable (package-git, package-svn, etc.) versions of source packages, but you must always search first the CCR and the repositories, since some of them might be already available, even not being a stable release (like Calligra).
- Disown your packages if you are not maintaining them anymore.
CCR Trusted User
CCR Trusted Users oversee the Chakra Community Repository.
With time, some CCR Packagers might get to feel quite comfortable with package creation and being part of the Chakra community. These packagers may be nominated by a Trusted User to become Trusted Users themselves.
- CCR Packager's rights.
- Change the category of source packages from other users.
- Disown source packages from other users.
- Delete source packages from other users.
- Nominate and vote for new Trusted Users.
- Read profile of other users.
- Disable accounts.
- Remove accounts.
- See the voters for an app.
- CCR Packager's responsibilities.
- Change category of packages in the wrong one.
- If a maintainer is not taking the right care of one of his or her packages and someone else is willing to take the maintainer's place, disown the package from the current owner after giving them at least two weeks notice by comment or e-mail.
- Make sure no duplicate source packages get uploaded to the CCR with a different name, and if so, notify the uploader and deleted the source package.
- Nominate those CCR Packagers you think can be trusted to become Trusted Users, and vote whenever there is a proposal for a new Trusted User.
- Warn those users not following the rules, and disable their accounts for a certain period of time if needed (first discuss it with other Trusted Users).
- Remove accounts of users creating source packages with malware, or fake source packages.
- Remove fake accounts created to increase votes for a source package.
- Don't disown a package until you have someone to maintain it, and try to avoid orphaned packages by adopting them.
- If you find upstream issues when packaging, try to get in contact with the developers and provide them with feedback so the issues can be solved. If you create or find a patch, make sure developers know about it.
- Join packagers and CCR mailing list to get in touch with other packagers and be aware of any news.
Junior Packagers maintain the [desktop], [gtk] and [lib32] binary repositories.
CCR Trusted Users may eventually become Junior Packagers if they want to and prove they are up to the task. New Junior Packagers are chosen by current Senior Packagers, who will also mentor them in any step needed.
Applicants should play around with the build systems a couple of times, for different repositories and packages, so they understand how they are designed and supposed to work. Later they can build some packages and test them locally - and preferably in a few other systems, to make sure all was done correctly.
Before committing anything to the official repositories, you need to get some packages reviewed.
Once your packages get validated by an Senior Packager, you can ask the Senior Packager to make an access request on your behalf.
- CCR Trusted User's rights
- Git access to git.chakraos.org
- Shell access to rsync.chakraos.org
- CCR Trusted User's responsibilities
- Upload new packages to either [desktop], [gtk] or [lib32], depending on its type, whenever new (most) stable versions are available.
- Make sure your shell account (user and password) are kept in secret and up to date, as well as your e-mail.
- Upload new versions of software to the [testing] repository first, and move them to stable after a week of testing.
- When updating a package, repackage also those packages depending on it. Run sudo pacman -Sii <package> to get a list of them (among other information).
- If you need a newer version of a package in [core] to package something, report it in the bugtracker.
- When repackaging, don't forget to increase the
pkgrelvariable in the PKGBUILD. Also, remember to put it back to
versionvariable is changed.
- Use one chroot at a time, and don't ever use pacman from outside the chroot while in the chroot (from a different terminal). You can screw your pacman configuration.
- Push to git from inside the chroot, not from outside.
- Don't try to remove a chroot with
rm. Run the build system script you used to create it, and you will be given the option to remove it.
Senior Packagers maintain the [core] binary repository.
Experience with build systems and packaging in general is needed. It's also a plus to be part of KDE, which makes it easier to maintain the repository.
The guidelines for working on core packages are explained in Packaging rules
There is no established process to become a Senior Packager.
- Junior Packager's rights.
- Junior Packager's responsibilities.
- Update packages in [core] when strictly necessary.
- Discuss changes to [core] with the other senior packagers first.
- Save a backup copy of any package you want to replace, so it can be restored if necessary.
- Test every package update in your machine before committing.