# deb-get for third-party Debian packages

> deb-get adds apt-style installation and upgrades for vendor repositories, GitHub releases, and direct .deb downloads on Debian-based systems. It is most useful for software that official repositories do not carry, but its package index and GitHub authentication requirements define its scope.

**wimpysworld/deb-get** — apt-get for .debs published via GitHub or direct download 📦

- Repository: https://github.com/wimpysworld/deb-get
- Stars: 1,779 · Forks: 192
- Language: Shell
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/wimpysworld-deb-get

## Why deb-get exists beside apt and dpkg

deb-get addresses a specific gap in Debian package handling: software that is distributed as a .deb but is absent from the distribution repositories already configured on the system. A vendor may publish its own apt repository, attach packages to GitHub releases, or offer only a direct download. Each arrangement normally requires a different manual procedure, and those procedures may not provide one consistent way to list, install, remove, or upgrade the software.

The intended audience is Debian, Ubuntu, and derivative system administrators or individual users who want apt-like commands for this category of third-party software. The README specifically points to applications that are not officially packaged, move faster than distribution packages, or have licensing constraints that limit redistribution. It does not claim to replace apt, dpkg, or every desktop software installer.

The important boundary is the curated package index. deb-get can operate only on applications represented by package definitions maintained for the project. An available .deb on a vendor site does not automatically become installable through a package name typed into deb-get install. The README documents discovery through deb-get list and deb-get search <regex>, which makes the catalog part of the user experience rather than an implementation detail.

Its command vocabulary also assumes package-management familiarity. Commands such as update, upgrade, install, remove, purge, and cache resemble apt because the intended workflow is predictable for Debian and Ubuntu users. The resemblance does not mean behavior is identical for every source. Package definitions determine how an artifact is fetched and which update mechanism applies.

## Repository packages, release assets, and direct downloads

The repository layout separates package information from the main Shell entry point named deb-get. Top-level directories include 01-main, 00-builtin as referenced by the CLI documentation, debian packaging, and supporting documentation. This suggests a catalog organized as repository data consumed by the command-line tool, although the README does not document the complete internal schema or every field in a package definition.

Two source categories are explicit. An apt or PPA package definition can lead deb-get to initialize and update an external repository. A direct-download definition can retrieve a .deb published by a vendor website or attached to a GitHub release. GitHub is not merely a documentation site in this workflow. The README requires a GitHub Personal Access Token in the DEBGET_TOKEN environment variable for authorization with the GitHub API and warns that omitting it causes failures during update, upgrade, and install.

That token requirement has operational consequences. A nominally simple installation can fail before the requested package is fetched because GitHub API authorization is absent or unsuitable. The README links to GitHub's authentication documentation but does not state which token scopes or fine-grained permissions are required. That point must therefore be verified in the live GitHub account settings and with deb-get itself rather than inferred from the project description.

The local cache is /var/cache/deb-get. The cache command lists its contents, while clean clears retrieved package files from that directory. The documentation does not describe cache expiration, signature verification policy, retry behavior, proxy support, or whether every source passes through the same validation path. Those omissions matter for production use because repository trust and failed downloads are package-management concerns, not just network details.

## Install deb-get and configure GitHub authorization

The documented installation method executes the project's main script from GitHub with the install argument. The prerequisite command installs curl, lsb-release, wget, and jq through apt. Because the project uses a GitHub-hosted raw file, network access and careful review of any remotely executed administrative script are relevant to the operation.

Run the commands documented by the project as follows:

```bash
sudo apt install curl lsb-release wget jq
curl -sL https://raw.githubusercontent.com/wimpysworld/deb-get/main/deb-get | sudo -E bash -s install deb-get
```

The first line installs the documented prerequisites. The second downloads the deb-get entry point and invokes it with root privileges. The README does not document expected output for this operation, so the reader should use deb-get version after installation to confirm that a command is available.

A manual package path is also documented:

```bash
sudo apt-get install ./path/to/deb-get_<version>.deb
```

That command is a template rather than a ready-to-run path. The release asset must first be downloaded and its version substituted in the filename. The README does not describe checksum verification for that manual download.

GitHub operations require the token environment variable. The documented setup is:

```bash
export DEBGET_TOKEN=github-personal-access-token
deb-get update
deb-get upgrade
```

Replace the placeholder only with the token value assigned to the current shell or its secret-management mechanism. The README does not explain how to persist the variable for root or another user, so the deployment-specific handling of that secret must be determined separately.

## Discover and inspect a supported application

A first installation should begin with discovery rather than guessing a package identifier. The README gives Google Chrome as its primary example, but the command name must correspond to an entry in deb-get's catalog. The list command can show all supported packages and their installation state. The search command accepts a regular expression.

```bash
deb-get list
deb-get search chrome
```

The plain list operation is slower because it checks which applications are installed. For faster catalog output, the documentation offers --raw, --installed, and --not-installed. The --include-unsupported option changes catalog filtering by including unsupported architectures, upstream codenames, and PPAs for Debian-derived distributions.

Before installation, deb-get show can report information for one package or several packages, including the install source and update mechanism. That is the most useful project-specific inspection command for deciding whether a package comes from an apt repository, GitHub, or direct download. The README gives no sample output, so it would be inaccurate to promise specific repository names, architecture fields, or version labels in the display.

For package administration, upgrade without options installs the newest versions of all packages currently installed on the system. That wording is broader than an obvious command name might suggest. Users who want to restrict the operation to applications installed through deb-get should use the documented --dg-only option. Likewise, update normally resynchronizes apt package indexes and checks for updates, while --repos-only limits the action to deb-get's external repositories without updating apt or looking for installed package updates.

## Install Google Chrome through a catalog definition

The README's concrete first-use example is Google Chrome:

```bash
deb-get install google-chrome-stable
```

This command should not be read as a universal installer for arbitrary .deb URLs. The name google-chrome-stable is supplied because the project maintains a corresponding package definition. Once the install completes, deb-get can later update packages it manages with deb-get upgrade or restrict the scope with deb-get upgrade --dg-only.

The command accepts one package or a space-separated list. This permits a single invocation to cover several catalog entries, but the documentation does not describe transaction selection, dependency resolution differences, rollback behavior, or recovery after a partial failure. Those boundaries should be treated as unknown rather than inherited automatically from apt's documented behavior.

Removal offers two related choices. remove follows the package-management operation for removal, while purge also deletes configuration files. Adding --remove-repo tells deb-get to remove the apt repository for packages sourced from an apt repository or PPA. This option is source-specific and should not be treated as a request to delete unrelated system repositories.

The README also includes reinstall for packages whose definitions changed or whose installation needs repeating. A separate fix-installed command can repair installed packages whose definitions changed, but its documentation explicitly describes --old-apps as a transition command intended for internal use. Ordinary users have no documented requirement to run fix-installed.

## Maintenance, upgrades, and the cost of package definitions

The repository is not archived, and its last push was on 2026-09-20. Recent releases listed include 0.4.7 on 2026-06-22, 0.4.6 on 2026-01-22, and 0.4.5 on 2025-04-15. These dates show recent project activity, but the README does not define a compatibility policy, supported-release window, or migration procedure for each deb-get version.

Maintenance effort is split between the Shell program and its curated application definitions. A repository URL, release asset, architecture, distribution codename, checksum, package name, or update method can become stale as vendors change their publishing systems. The existence of fix-installed for changed definitions confirms that catalog maintenance can affect installed systems. However, the README does not say whether definition changes are automatically reconciled during a normal upgrade or require that command.

Upgrading deb-get itself is separate from upgrading the third-party applications it installed. The usage text describes deb-get upgrade as package installation or update behavior for managed packages, but it does not provide a dedicated command or documented procedure for upgrading the deb-get program itself. An operator using the remote installation command will retrieve whatever is currently on the main branch, whereas a manual user can install a named release asset. Those two installation paths can therefore produce different version-selection behavior.

The project uses the MIT license. That permits broad use, modification, and redistribution under the license's conditions, but this review does not interpret its legal effect. Package definitions can also refer to third-party software with separate licenses and distribution terms, which are outside the scope of deb-get's own license.

## Where deb-get is the wrong package-management choice

deb-get is a poor fit for software already covered by properly configured Debian or Ubuntu repositories. Adding a second catalog path for an application that apt manages can make source selection and update ownership less clear. In that case, an apt source configured by the distribution or vendor is the more direct mechanism.

It is also the wrong tool for arbitrary local .deb files whose applications have no deb-get package definition. dpkg or apt can install a local package directly, while deb-get's value depends on a maintained definition that describes how to find, install, update, and remove the application. Likewise, software distributed only as AppImage, Flatpak, container image, source archive, or an operating system installer package falls outside the documented .deb-focused workflow.

The command name creates a reasonable expectation of complete apt parity, but the documentation does not confirm rollback, dependency-solving details, hold support, downgrades, signing requirements, conflict recovery, or unattended upgrade integration. The absence of documented support does not prove that a feature is impossible, but engineers should not make an adoption decision based on assumed apt semantics.

Finally, environments that cannot issue GitHub API credentials have a concrete constraint. The README says update, upgrade, and install can fail without DEBGET_TOKEN. For direct apt-repository packages, the need may not be equally relevant, but the README presents the PAT as a required setup step rather than documenting per-source exceptions. This deserves testing before the tool enters a managed image or provisioning workflow.

## Conclusion

Adopt deb-get when an organization repeatedly installs vendor-maintained .deb packages outside apt's configured repositories and can manage a GitHub token and package index. Do not adopt it as a general-purpose replacement for apt or assume its curated catalog covers every Debian or Ubuntu package. Before adoption, verify that the intended applications are returned by deb-get list, inspect the source and update mechanism shown by deb-get show, and test the required DEBGET_TOKEN configuration on a disposable system.

## FAQ

### Does deb-get need a GitHub Personal Access Token?

The README requires a GitHub Personal Access Token in DEBGET_TOKEN and warns that update, upgrade, and install can fail when this step is skipped.

### How do I find applications supported by deb-get?

Use deb-get list to see supported applications and their installed state, or deb-get search <app> to search the catalog with a regular expression.

### Can deb-get upgrade only packages that it installed?

Yes. The documented command is deb-get upgrade --dg-only, while deb-get upgrade without that option addresses the newest versions of all packages currently installed on the system.

## Sources

- [Issues](https://github.com/wimpysworld/deb-get/issues)
- [License: MIT](https://github.com/wimpysworld/deb-get/blob/main/LICENSE)
- [README](https://github.com/wimpysworld/deb-get/blob/main/README.md)
- [Releases](https://github.com/wimpysworld/deb-get/releases)
- [wimpysworld/deb-get on GitHub](https://github.com/wimpysworld/deb-get)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wimpysworld-deb-get