Release 1.6

Release 1.6

This is release is very interesting because it finally makes the dist-git package independent of any particular distro (most notably Fedora), which means you can easily use it for your own setups. Everything relevant can be toggled by configuration options. Let's see the default configuration file containing all the available options:

[dist-git]
git_author_name  = Fedora Release Engineering
git_author_email = [email protected]

cache_dir      = /var/lib/dist-git/cache
gitroot_dir    = /var/lib/dist-git/git

gitolite       = True
grok           = True
fedmsgs        = True
old_paths      = True
nomd5          = True

default_namespace = rpms

The first two options git_author_name and git_author_email are used by setup_git_package script that sets up new DistGit repositories. It will read those options and use them to set git.config.author and git.config.email configuration variables in the created repository. Afterwards, the script will create an initial commit in the repository with those values set.

Next two options cache_dir and gitroot_dir configure where your Git repositories are placed on your server and also where your lookaside cache (that stores source files) is placed. Note that default SELinux policy being shipped in dist-git-selinux subpackage is configured paticularly for these two default paths. To be able to change those settings, you will need to make a custom SELinux policy. Please, take an inspiration here: https://github.com/release-engineering/dist-git/tree/master/selinux.

Next is gitolite (http://gitolite.com/gitolite/index.html), which is as system that enables you to do fine-grained access control upon your Git repos (e.g. branch-level access control). If you would like to use Gitolite, you can set this option to True (default) and setup_git_package will then setup Gitolite-specific update hook that invokes Gitolite code upon repository updates (pushes, tag and branch creations, etc.).

grok setting works similarly. When enabled /usr/bin/grok-manifest will be invoked upon receive events, which will automatically regenerate manifest.js.gz file in your main repodir. That file contains information about recent repository updates to make an effective mirroring possible. You can read a tutorial here: https://www.kernel.org/mirroring-kernelorg-repositories.html if you are interested.

fedmsgs setting configures whether or not fedmsg should be sent upon each upload into the lookaside cache. You can keep this True if you would like to be informed (or inform other systems) about this event.

old_paths setting toggles on/off a deprecated behavior of the upload.cgi script (that does all the heavy-lifting around the source uploading) to hard-link the sources files path containing the hash type specification (e.g SHA512, md5) to path that does not have this part included. Even if this setting is True, it actually won't do anything unless nomd5 is set to False because the old paths are a historical artifact from times when only md5 was used for check-summing.

The nomd5 settings can be used to explicitly disallow uploads that contain md5 checksum and only allow those that used more secure (e.g. SHA256, SHA512) hashes.

Finally default_namespace specifies where to setup new Git repositories and where to upload new source packages when the name of the package in the received data does not contain any namespace specification: i.e. instead of <namespace>/<pkgname>, just pkgname is received as the input value for package name. You can remove this setting or set no value (default_namespace = ) if you would like all the Git repositores to be stored in the same directory.

Note that all of the options are currently set to True by default but that does not mean it is a good default for you. E.g. Gitolite is quite heavy-weight and if you are alright with just repository-level access control, you will very likely want this option to be set to False.

For communication with your DistGit setup (source uploading, repo cloning, etc.), python-rpkg library can be used (https://pagure.io/rpkg). There are also existing command-line utilities based on this library that you can easily use, most notably rpkg and fedpkg. There are more tools out there (e.g. centpkg) but we haven't tested DistGit with those tools yet. There should not be many incompatibilities, however.