|
| 1 | +# README for Debian packaging contributors # |
| 2 | + |
| 3 | +This documentation describes how to contribute to the official Debian packages |
| 4 | +of MariaDB. The packaging in Debian repositories is not identical to the packaging |
| 5 | +in mariadb.org repositories, but whatever is in Debian repositories will eventually |
| 6 | +be upstreamed. |
| 7 | + |
| 8 | + |
| 9 | +## Development environment and tools |
| 10 | + |
| 11 | +Use a recent version of Debian or Ubuntu as the environment for Debian packaging |
| 12 | +testing and development. Preferred environment is Debian Sid (unstable). |
| 13 | + |
| 14 | +Install the tool used to manage and build the source |
| 15 | + sudo apt-get install git-buildpackage |
| 16 | + |
| 17 | + |
| 18 | +## Getting the source |
| 19 | + |
| 20 | +The official Debian package source is available at |
| 21 | + * git://git.debian.org/git/pkg-mysql/mariadb-10.0.git |
| 22 | + * (browseable at http://git.debian.org/?p=pkg-mysql/mariadb-10.0.git |
| 23 | + |
| 24 | +However, git.debian.org does not provide any kind of pull request or gerrit |
| 25 | +work-flow, so it is recommended to fork the Github mirror available at |
| 26 | + * https://github.com/ottok/mariadb-10.0 |
| 27 | + |
| 28 | +Once you have a fork at Github, clone the source repository with all relevant |
| 29 | +branches (master, upstream, prisine-tar) to your local environment |
| 30 | + gbp-clone --pristine-tar [email protected]:{username}/mariadb-10.0.git |
| 31 | + |
| 32 | +Clone needs to be run only once. On later runs you can refresh your clone with |
| 33 | +relevant branches using |
| 34 | + gbp-pull --pristine-tar --force |
| 35 | + |
| 36 | + |
| 37 | +## Building the packages |
| 38 | + |
| 39 | +Build binaries, run testsuite and build Debian packages with |
| 40 | + git-buildpackage |
| 41 | + |
| 42 | +On the first run git-buildpackage will complain if some of the build dependencies |
| 43 | +defined in debian/control is missing. Simply install those packages and run the |
| 44 | +build again. |
| 45 | + |
| 46 | +If the build fails, the easiest way to clean up before a new run is |
| 47 | + git clean -f -d && git reset --hard |
| 48 | + |
| 49 | + |
| 50 | +### Build options |
| 51 | + |
| 52 | +If you want to skip the mysql-test-run step (which takes a lot of time) set |
| 53 | +the following environment variable: |
| 54 | + export DEB_BUILD_OPTIONS="nocheck" |
| 55 | + |
| 56 | +If you want to run the build in parallel on 2 CPUs and have verbose output: |
| 57 | + export DEB_BUILD_OPTIONS="parallel=2 verbose" |
| 58 | + |
| 59 | +The options above can also be combined freely to get desired behaviour. |
| 60 | + |
| 61 | + |
| 62 | +## Creating a feature or bugfix branch |
| 63 | + |
| 64 | +The repository has the following branch layout: |
| 65 | + * upstream - contains the upstream source releases without modifications |
| 66 | + * pristine-tar - contains extra delta needed to re-create the original |
| 67 | + tarballs with the exactly same SHA-1 hash as the original tarballs by upstream |
| 68 | + * master - packaging for Debian Sid (unstable) |
| 69 | + * jessie - release branch for Debian Jessie |
| 70 | + * ubuntu-15.04 - release branch for Ubuntu 15.04 |
| 71 | + |
| 72 | +All new features and also bugfixes are done only in the master branch. The |
| 73 | +release branches for Debian and Ubuntu are only used for security updates. |
| 74 | + |
| 75 | +To prepare the Github pull request, create a bugfix branch from master with: |
| 76 | + git checkout -b fix-example-name |
| 77 | + |
| 78 | +After this you can develop with all the usual git commit and push commands |
| 79 | +until you have in your fork at Github the desired change and you are ready |
| 80 | +to open the pull request. |
| 81 | + |
| 82 | + |
| 83 | +### Notes about how to make changes in the proper way |
| 84 | + |
| 85 | +Please use gitk or similar tool to browse the previous changes. Try to follow |
| 86 | +similar pattern in your new changes. |
| 87 | + |
| 88 | +Keep in mind that all changes must done only for files residing in the debian/ |
| 89 | +subdirectory. If you need to create changes outside the debian/ directory, |
| 90 | +then you need to create a patch file using the same pattern as the patches |
| 91 | +found in debian/patches and activated by a line in debian/patches/series |
| 92 | + |
| 93 | +Whatever you change is, you should bundle in you commit also a short description |
| 94 | +in the file at debian/changelog |
| 95 | + |
0 commit comments