Development/Task/Packaging/MaintainersQuickStart

From Mandriva Community Wiki

Jump to: navigation, search

Contents

New maintainers quick start guide

So, you want to become a Mandriva maintainer, and you have already followed up the steps outlined in the Development/Resources/Account#Applying, have found a mentor to sponsor you, have your @mandriva.org account working, have subscribed to the maintainers mailing list, updated your my.mandriva.com registration and bugzilla account, and are eager to start working.. so now you should learn about how Mandriva build system works, and what is expected from the maintainers.

Caution !
From 2011 onward, a draft of the policy which Mandriva maintainer should follow is available at maintainers policy. Please take a careful look at it, to know what would be your roles and tasks.

If you agree to all that, and want to start contributing and maintaining packages belonging to Mandriva repository, here is a short guide to lead you through most of the tasks.

Building and working with packages

The general steps are described here. Please take a read on it, and experiment with the repsys and mdvsys utilities, bm or rpmbuild applications. Try extracting a package from the build system and building it locally.

If you are not familiar with RPM, then howto RPM is a must-read.

Take a look on how package files are organized inside the repository and how repsys/mdvsys extract them. Note that only SPECS/ and SOURCES/ files are stored in the svn. Binary rpm files and source rpms (srpms) are generated by the build system automatically, and you should not add or commit them into the package.

Please take a good look at Mandriva Policies. A must-read list consists of Post-Release Support, Bug policy, and all of the Packaging policies.

Familiarize yourself with the rpmlint application. It will prevent you from having your build rejected by the build system, and also help you standardize your specs and files to the common format used in Mandriva packages.

Please note!
When in doubt, take a look on other packages. Most of the issues can be quickly solved by looking how other maintainers did it in the past.

Memorable links that you should bookmark, and which will be very useful to you in the future are:

And of course, in case of any questions, feel free to ask your mentor. He is there for it!

Quick step-by-step guide to repsys

A quick step-by-step guide for maintaining a package using repsys follows:

  • repsys co <packagename>
This will extract the package from the repository
  • cd <packagename>
All the packages related to the package building should be located within this directory. Take a look on what directories are there. The .spec files are located in SPECS directory, and all the sources should live within SOURCES. The BUILD directory is using for building your package; and BUILDROOT is a temporary directory where package installation goes before it is transformed into rpm files.
  • Build your package with bm. Discover what bm -l, bm -pl and bm -ls commands do.
  • Run rpmlint command on your spec file and pay a close attention to all the errors and warnings it gives.
  • Install and test your package locally. If there is some issues, you will be able to discover it more quickly this way and avoid breaking the package.
Make sure to use urpmi --test packages/to/install to quickly find issues without carrying out a real installation.
  • When ready, commit your changes with svn commit. Make sure to increase the %mkrel number if it is just a release bump, or use %subrel when building an update for a stable distro (see support policy).
  • To quickly syncronize your changes with repository, you can use repsys sync command. It can also be used to automatically download missing missing files, and updating packages to the latest version.
  • When everything is tested, committed and works, use the repsys submit command to send the package to the build system.
Please note!
Note that for first releases, your mentor will run the repsys submit for you, and check your packages. When your packaging skills and number of possible problems will improve, you will be granted the rights to run repsys submit directly.

Sample repsys session

  • Fixing a problem in application SPEC:
 # repsys co mpdscribble
 # cd mpdscibble
 # vi SPECS/mpdscribble.spec
 # bm -l
 # urpmi --test RPMS/*/*rpm
 # urpmi RPMS/*/*rpm
 # (run the application and certify it works)
 # svn commit
 # repsys submit
  • Fixing a problem in some of the patches (for example, SOURCES/mpdscribble-1.2.3-fix.patch):
 # repsys co mpdscribble
 # cd mpdscibble
 # vi SPECS/mpdscribble.spec
 # (look for the line where the patch is defined - for example, Patch0:  mpdscribble-1.2.3-fix.patch)
 # (look for the line where the patch is applied - for example, %patch0 -p1, and add an 'exit' line before it)
 # bm -pl
 # (this will setup the sources, apply all the packages, and exit before Patch0 is applied)
 # cd BUILD/mpdscribble-1.2.3/
 # cat ../../SOURCES/mpdscribble-1.2.3-fix.patch | patch -p1 -b -z .fix
 # (this will apply the problematic patch, and save the original files modified by it with a .fix extension)
 # (fix the issues that must be fixed)
 # cd ../ (go to the BUILD directory, and, within the BUILD directory, run:)
 # gendiff mpdscribble-1.2.3/ .fix > ../SOURCES/mpdscribble-1.2.3-fix.patch
 # (this will regenerate the patch with your fix)
 # vi SPECS/mpdscribble.spec (increase %mkrel value to show that this will be a new release; and uncomment that 'exit' line so the patch would apply now)
 # bm -l
 # urpmi --test RPMS/*/*rpm
 # urpmi RPMS/*/*rpm
 # (run the application and certify it works)
 # svn commit
 # repsys submit
  • Updating the package to a new version (easy way, when SPEC provides full path to package sources)
 # repsys co mpdscribble
 # cd mpdscibble
 # vi SPECS/mpdscribble.spec
 # (update the Version: to the new version - for example, 1.2.4, and reset %mkrel back to 1)
 # repsys sync -d (this will automatically download the files from the upstream and sync them with the SVN)
 # bm -l
 # urpmi --test RPMS/*/*rpm
 # urpmi RPMS/*/*rpm
 # (run the application and certify it works)
 # svn commit
 # repsys submit
  • Updating the package to a new version (hard way, when SPEC does not provides full path to package sources)
 # repsys co mpdscribble
 # cd mpdscibble
 # vi SPECS/mpdscribble.spec
 # (update the Version: to the new version - for example, 1.2.4, and reset %mkrel back to 1)
 # (download new version from Upstream, and place it into SOURCES directory)
 # repsys sync (to syncronize svn entries automatically)
 # bm -l
 # urpmi --test RPMS/*/*rpm
 # urpmi RPMS/*/*rpm
 # (run the application and certify it works)
 # svn commit
 # repsys submit
  • Submitting a package to backports (for example, to 2010.1 backports)
 # repsys co mpdscribble
 # cd mpdscibble
 # repsys submit --define section=contrib/backports -t 2010.1
  • Checking out version from a supported distro (for example, from 2010.1)
 # repsys co 2010.1/mpdscribble
  • Submitting a build to main/testing for a supported distro
 # repsys co 2010.1/netprofile
 # (do all the fixing)
 # repsys submit --define section=main/testing -t 2010.1

Quick step-by-step guide to mdvsys

(TODO, with base on previous section and http://wiki.mandriva.com/en/Development/Packaging/BuildSystem/QuickRef)

Common problems and solutions

  • Most issues and their solutions are already described here. In case of problems when compiling package, make sure to check it. Really:
  • To understand how the repositories are organized, supported and used, check this link:
  • If you want to have a local environment for automatically rebuilding your packages in chroot, similar to one used by the Build System, you may install the iurt package. Please note that it will require either a local mirror of Mandriva repositories, or a fast system to download and install packages.
    • (TODO: write some tutorial on how to use iurt)
  • Documentation about random technical topics related to packaging and application-specific issues is usually here:
Personal tools