Dgit brings Git to the Debian archive
Git Happy
Dgit combines the Debian archive with a Git repository, giving package maintainers some totally new options for managing Debian source packages.
Version management systems are a fundamental building block of professional software development. Many projects use Git [1], a version control tool created by Linux founder Linus Torvalds for the Linux kernel developer community. Git offers a distributed development environment with many benefits, such as revision management and flexibility with exchanging code, but it is difficult for a development project with large, legacy archives to interface with the Git environment. A helpful tool known as dgit brings the power of Git to the entire Debian archive. See Table 1.
Table 1
Package Maintenance Workflow with dgit
Command | Comment |
---|---|
dgit clone project |
Retrieve any package from the archive |
cd project/ |
Change to the source directory |
git branch |
Check the current Git branch; result: |
git remote add upstream https://github.com/developer/project |
Set up an upstream repository as an additional remote |
dch -i |
Increment package version in |
Source Package On-Going Development |
|
debcommit -a -e |
Commit with the last Changelog entry as a message |
git status |
Check for overlooked files |
sudo sbuild-createchroot unstable /var/lib/sbuild/unstable-amd64 http://httpredir.debian.org/debian/ |
Set up an Sbuild chroot (architecture also needs to be adapted) |
dgit -wdd --mergechanges:-i sbuild |
Build a new source and binary package with Sbuild |
lintian -iI --color=auto ../projekt_1.0.0-1_amd64.changes |
Check built packages for problems (package: |
sudo dpkg --install ../projekt_1.0.0-1_amd64.deb |
Install binary package |
dgit push |
Upload new package to archive, tag current commit and synchronize with Dgit repository |
Dgit which was created by Ian Jackson, treats the whole Debian archive as a version control system and serves as a "bidirectional gateway between the archive and Git." Dgit [2] lets users load arbitrary source packages from the archive into a local Git repository, then work on them with Git techniques, and finally build the binaries (Figure 1). Package maintainers can use dgit to feed their changes back into the Debian archive.
Clones
Developers install dgit as a CLI tool. The dgit clone <packagename>
command (Figure 2) retrieves any source package from the Debian archive [3]. This step is equivalent to calling apt-get source <packagename>
, although you do not need to state a deb-src
package source in the /etc/apt/sources.list
file. After downloading with dgit, you'll be missing the registry file (.dsc
) and the tarball with the Debian files (.debian.tar.xz
), but there is no need to unpack the source package using dpkg-source -x
.
The source directory is now controlled by Git; you can check this by going to the source directory and by typing git status
. To see whether someone has already managed the package with dgit, you can run the git log
command. If not, you will see a comment telling you that the package was imported from the archive.
If you do not specify a Debian branch (using dgit <packagename> <branch>
), Debian retrieves the source package from the Unstable developer version. You can verify this branch name by reference to the name of the current Git branch by typing git branch
; in the example, the response will be dgit/sid
.
Package Maintenance
Administrators maintain packages by writing patches for changes to the upstream code or modifying the control files in debian/
. Dgit offers you all the Git options for your work on the source directory, thus providing an uncomplicated way of trying things out and reworking changes that you stored, or letting you simply discard the changes. If desired, you can use experimental Git branches for your development.
Debian maintainers can use Debian package maintenance tools in a Git repository (Figure 3). For example, Debcommit (package: devscripts
) automatically generates commit messages from entries in debian/changelog
.
Some developer groups have been maintaining their packages in public Git repositories for a long time. The matching URL is stored in the Vcs-Git
field of the debian/control
file. Dgit automatically sets up the group repository as an additional remote repository after cloning; this leads to a Remote: vcs-git
entry in the .git/config
file.
For a three-way exchange of code, users could include the upstream repository to the Git remotes. It's easy to use this source for cherry-picking from the latest code in a local copy of the upstream repository in Debian patches.
Building
If you want to upload a new package version to the archive or generate binary packages (.deb
), you can build from within the Git directory. Dgit offers wrappers for various build tools, such as the chroot builder Sbuild [4]. If a chroot [5] of Unstable already exists, dgit builds the new source package along with the binary packages with the dgit sbuild
command, optionally in a RAM overly. However, you need to specify the dgit cleaning option, -wdd
, to work around the availability check before changes to the chroot environment.
Another useful default setting in dgit is automatically applying the mergechanges scripts after the build (package: devscripts
). This setting references the _<arch>.changes
file to create another _multi.changes
file that is suitable for source-only uploads. Dgit prefers this approach when uploading; the Build network then rebuilds the binary package for the architecture used locally – which is the generally recommended approach. For this strategy to work properly, you need to specify the --mergechanges:-i
dgit option or configure the tool with this option.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.