Translation(s): none

Salt Packaging Team

It is early days for the salt packaging team, but we are setting up the infrastructure.

Our aims are to package salt and then the other salt tools (salt-api, salt-cloud etc) for debian and subsequently ubuntu.

Our primary aim at this point is firstly getting salt into debian unstable and hopefully being backported to wheezy and squeeze. Following this, we will be repeating this process for the other salt tools.

Most of the information below is for the team to learn, agree and standardize on processes for setting up and working with the repository we will use for packaging. Although it contains information that may be useful for building your own salt packages, that is not the intention at this stage. For the moment, the best reference is probably http://docs.saltstack.com/topics/installation/debian.html.

If you wish to be involved, the best approach is probably to join the mailing list.

Infrastructure

• Alioth Project: http://alioth.debian.org/projects/pkg-salt

• Repository: git+ssh://git.debian.org/git/pkg-salt/salt.git

Interacting with the team

• Email contact: <pkg-salt-team@lists.alioth.debian.org>

• Mailing list: https://lists.alioth.debian.org/mailman/listinfo/pkg-salt-team

• Salt Package QA Page: salt

Task description

Packaging of Salt (http://saltstack.com) and related projects.

Related

HowTos

Day to Day work

In your working location, either:

gbp pull 

or

git pull --all
git pull --tags

Do work, then commit and push:

git push --all
git push --tags

Importing a new salt release

gbp import-orig ../salt_2016.11.8+dfsg1.orig.tar.gz --pristine-tar

Patching the repository

Depending on the need, this should either be done by using quilt (http://www.debian.org/doc/manuals/maint-guide/modify.en.html) or by modifing the debian/rules file.

In a recent (and educational) example, the rm was added at the end of the override_dh_installdocs chunk to delete the .DS_Store file after the files were copied into the temporary packaging location (dh_install/dh_installdocs step) but before being packaged into the .deb file.

rm -r was used rather than rm -rf (force) so that when a fixed upstream release is made, this will fail and the patch can be removed.

The extract from debian/rules can be seen below:

override_dh_installdocs:
        dh_installdocs
        # Remove embedded copies of javascript libs
        for f in $(JS_FILES) ; do \
                cd debian/salt-doc/usr/share/doc/salt/html/_static/ \
                  && rm $${f}.js \
                  && ln -s ../../../../javascript/sphinxdoc/1.0/$${f}.js . \
                  && cd $(CURDIR) ; \
        done ;
        # Remove stray .DS_Store file
        rm -r debian/salt-doc/usr/share/doc/salt/html/_static/fonts/.DS_Store

Building the packages

Is this the best? Some people use pbuilder - should that be our standard process?

gbp-dch --id-length=7

gbp buildpackage  -us -uc

Once you are happy with the packages

gbp buildpackage --git-tag -us -uc
git push --all
git push --tag

Cloning the repo down

As it is a git-buildpackage repo, the following will clone the branches down properly:

gbp clone git+ssh://username-guest@git.debian.org/git/pkg-salt/salt.git

Testing the packages

1. Install on sufficiently clean system
2. Uninstall
3. Install previous version
4. Upgrade to new package
5. Test basic package functionality

Backporting

If we backport to squeeze, we may need to be aware of 698901

Decisions

1. Use of git and git-buildpackage for VCS

Proposed Decisions