manSavane - Cookbook: recipe #125, Packaging Savane

Show feedback again

recipe #125: Packaging Savane


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:

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:

Repackaging means be available also to fix the new package if there's any problem with it.


You need a debian system able to build packages. You need to have your GPG signature identified in the project keyring (please check!).

(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)

For example, you can do:

where XXX is the revision of the commit when you created the new tag. And afterwards, indeed do a svn commit.

Last update: Wed Nov 15 08:12:32 2006






Audience and Context

   All Project Members
   Download Area
Show feedback again

Back to the top

Powered by Savane 3.1-cleanup