Documentation< Previous | Contents | Next >
1.2.2. Managing the Difference with Debian
As a design decision, we try to minimize the number of forked packages as much as possible. How- ever, in order to implement some of Kali’s unique features, some changes must be made. To limit the impact of these changes, we strive to send them upstream, either by integrating the feature di- rectly, or by adding the required hooks so that it is straightforward to enable the desired features without further modifying the upstream packages themselves.
The Kali Package Tracker10 helps us to keep track of our divergence with Debian. At any time, we can look up which package has been forked and whether it is in sync with Debian, or if an update
9https://www.debian.org/releases/testing/ 10http://pkg.kali.org/derivative/kali-dev/
is required. All our packages are maintained in Git repositories11 hosting a Debian branch and a Kali branch side-by-side. Thanks to this, updating a forked package is a simple two-step process: update the Debian branch and then merge it into the Kali branch.
While the number of forked packages in Kali is relatively low, the number of additional packages is rather high: in April 2017 there were almost 400. Most of these packages are free software complying with the Debian Free Software Guidelines12 and our ultimate goal would be to maintain those packages within Debian whenever possible. That is why we strive to comply with the Debian Policy13 and to follow the good packaging practices used in Debian. Unfortunately, there are also quite a few exceptions where proper packaging was nearly impossible to create. As a result of time being scarce, few packages have been pushed to Debian.