Related Recipes:
Savane - Cookbook: recipe #125, Packaging Savane
recipe #125: Packaging Savane
RELEASE AND REPACKAGING, THEORY
There are two times when we want to build Savane package for the public: when when make a release, when we repackage a release.
Release are planned, there must be an open task on the project task tracker about it.
Repackaging can be done by experienced Savane developers whenever they feel it's necessary and for packaging issues only:
- to update translations
- to update documentation
- to fix bugs in packaging (update scripts, install scripts)
- in some cases, to fix a bug that make the release unusable in some case
As a repackaging implies risking to introduce new bugs, all the changes must appears necessary to improve the release without risking to break anything else.
Needlessly to say, there's no question that common bugsfixes do not justify a repackaging, they have to be included in a later release. And indeed, security fixes cannot be included in a repackaging but must be the occasion of a release.
Repackaging mean that's the previous package for the release will be replaced: this is supposed to be exactly the same release plus 1 change. The rationale behind is the idea that there's no reason to let people download by mistake the flawed package that contains the exact same release minus 1 change.
New package will not be specifically announced or whatsoever.
If you'd like to do a repackaging but:
- are not 100% sure it's appropriate
- are not 100% sure you are experienced enough with Savane development to do it please send a mail to savane-dev.
Repackaging means be available also to fix the new package if there's any problem with it.
PACKAGING HOWTO
You need a debian system able to build packages. You need to have your GPG signature identified in the project keyring (please check!).
- First, you have to pick the appropriate version name. If the release you repackage is name 1.1, the new version will be 1.1+1. If it's already 1.1+1, increment the later number (the repackaging number) and you get 1.1+2. If it is a new release, increment the first number of the release if there are major changes visible to the user, the second if its mainly a bugfix/cosmetics/minor changes releases.
- Copy the SVN tag of the version to be repackaged. For instance, you can do
(if it is not a repackaging, you will actually simply copy the trunk)
Then, you have to check out this new version:
In this new version checked out, you do whatever changes must be committed. You commit them on this tag.
(See the SVN manual, in doubt)
- Update debian/changelog appropriately (in emacs use "debian-changelog-mode"). Your new entry should looks like:
- Build the packages. In the savane directory, run
- Get with rsync a copy of the project download area (scp wont be ok, as it cannot creates symlinks):
For example, you can do:
- Put the packages in the relevant places:
- the tarball goes in the main directory
- the older tarball must be deleted (keep a copy in case something goes wrong)
- debian packages must go in debian/stable
- Add necessary additional data:
- the symlink savane-latest.tar.gz must be rebuilt against the new tarball
- debian/stable/Packages.gz must be rebuilt using by running `make update-deb-release` in the debian/stable directory.
- sign the new tarball with gpg (gpg --detach tarball) (Packages.gz should have been signed when it was recreated)
- Upload everything:
- Commit back your changes to the trunk, if you were doing a repackaging. To do that, check out the trunk, go inside its directory and use
where XXX is the revision of the commit when you created the new tag. And afterwards, indeed do a svn commit.
Audience and Context
Audience:All Project Members
Feature:
Download Area
Action:
Browsing
