*** PACKAGING ***

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 announce 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.

* Get the CVS with the tag of the release you want to repackage, add your
changes in this repository (the repackaging must not be based on the trunk!).

See the CVS manual, in doubt. 

* Update debian/changelog appropriately (in emacs use "debian-changelog-mode").
Your new entry should looks like:

##### entry begin
savane (1.45+1) unstable; urgency=low

  * Repackaging of 1.45, to fix a problem with that (bug #543245).

 --  Your name (on behalf of Savane developers) <savane-dev@gna.org>  Fri,  2 Sep 2005 23:27:59 +0200
##### entry end

* Build the packages. In the savane directory, run

	make deb-packages
	make tar rel=1.1+1

* Get with rsync a copy of the project download area (scp wont be ok, as it
cannot creates symlinks):

For example, you can do:
	
	# Get the content on dl.gna.org
	rsync -avr --rsh="ssh" YOURUSER@download.gna.org:/upload/savane .

* 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:

	# Put the content on dl.gna.org
	rsync --delete -avr --rsh="ssh" . YOURUSER@download.gna.org:/upload/savane


EOF
