Vulpine Package Manager

Vulpine as a group is an independent United Kingdom and Europe based software collaboration founded by Charlie, and later with Taylor under the BaronScott Consortium - a party of two.

Vulpine Linux is portable, micro-installable, persistent and transparent system thats defined as "terminal-first". Designed for standalone computing, micro-services, virtual environments and usable in micro, edge and embedded systems in which VPM was developed purposefully for!

Overview

VPM is a statically-compiled package manager written in C, designed to work within minimal environments where traditional package managers like APT or pacman would be impractical or inaccessible. It manages basic package installation, removal, updates, and dependency resolution while maintaining the minimal footprint and understand-ability that defines Vulpine Linux.

Built for clarity over convenience, VPM allows you to understand exactly what your system contains and how software is managed from installation through removal; whilst simple, it is effective as a first iteration package manager.

Features

• Installation deploying .vpm packages (pkgs)
• Dependency resolution and automatic dependency checking with version constraints
• Conflict detection preventing incompatible packages from being installed simultaneously
• Package scripts supporting preinst, postinst, prerm, and postrm hooks
• Simplified file tracking using hash-based file integrity verification
• Configuration protection preserving modified config files during updates
• Architecture support that tracks and manages architecture-specific packages
• Version constraint supports with classic >=, <=, >, < specifications
• Force removal which override dependency checks when necessary
• Automatic accept flag -y to get missing dependencies during install

Warning

This is a minimalist package manager intended for Vulpine Linux, though other operating systems can install and run the ./build.sh to compile vpm onto their systems you are doing so at your own risk!

Usage

Your system may require you to use sudo vpm, ensure that after running ./build.sh the vpm actually exists in your /bin/ directory or it may fail to run.

vpm get <package>              Gets a pkg to `/var/lib/vpm/` without installing
vpm install <package>          Install a package
vpm remove [-f|--force] <pkg>  Remove a package
vpm list                       List installed packages
vpm search                     Search available packages
vpm update <package>           Update a package
vpm c <directory>              Create a package from directory
vpm version                    Returns the current installed version

Installation Example

These packages do not exist unless they are on https://vpm.vulpinelinux.org/packages

vpm install {pkg} -y
vpm install {pkg}>=1.1.0,<=2.0.0

Removal Example

sudo vpm remove {pkg}
sudo vpm remove -f {pkg}

Creating Packages

Caution

We're about to discuss the creation of packages, if you've downloaded a third-party .vpm and it doesn't exist in sudo vpm search you should proceed with extreme caution; third-party packages are not verified or audited by the Vulpine Group.

To create a .vpm package from a directory:

vpm c /path/to/package-dir

The directory must contain:

• manifest for package metadata
• files/ the package files
• preinst, postinst, prerm, postrm scripts which are optional

Package Format

A .vpm file is a gzip-compressed tar archive containing:

package-name-1.0.0.vpm
├── manifest
├── files/
│   └── (your packaged files)
├── preinst (optional)
├── postinst (optional)
├── prerm (optional)
└── postrm (optional)

Manifest Format

name=package-name
version=1.0.0
arch=any
depends=libfoo>=1.0, libbar
provides=alternative-name
conflicts=incompatible-package

At the least any given manifest must provide name= and version=, an example of a complete minimal .vpm would be:

package-name-1.0.0.vpm
├── manifest
├── files/
│   └── var
│       └── lib
│           └── vpm
│               └── packages
│                   └── merk-0.051.950
│                       └── *

where-in merk-0.051.950 contains the files for your program.

The above example shows merk-0.051.950.vpm which will install to /var/lib/vpm/packages/merk-0.051.950/* as a result of its manifest and file structure.

We split get and install so that you can get a .vpm before installing it to perform self-audits if you prefer. Offering a way for you to verify something yourself before installing. All get packages are saved to /var/lib/vpm/packages, install installs packages from there or from vpm.vulpinelinux.org/packages if they're found in the search.

Making Your First .vpm Package.

We've done our best to keep it minimalist and simple - typically you can make a package by doing tar -czf {package-name}-{semantic_version}.vpm manifest files from the package root directory to compile a package. Replacing {package_name} and {semantic_version} with the ones in your manifest for example tar -czf cvsh-2.2.5.vpm manifest files.

If you are new to building a package, we get it can be a bit confusing.

You can run mkdir -p ./files/var/lib/vpm/packages/{program_name} && touch ./manifest replacing {package_name} with your program, borrowing from merk we could call this merk-0.051.950 and put your program files into that.

This will result in a file system similar to this:

├── files/
│   └── var
│       └── lib
│           └── vpm
│               └── packages
│                   └── {program_name}
├── manifest

If you're ever in doubt though, always reach out to the Vulpine Group through our support methods, we'd love to see you making a package for Vulpine and using .vpm!

Databases

VPM maintains several databases in /var/lib/vpm/:

• packages.db which stores installed packages and versions
• files.db tracking files using hashes
• deps.db which supports dependency relationships
• provides.db which is for virtual package mappings
• conflicts.db to control package conflicts

How to Contribute

We kindly ask that you focus on one-branch per feature or fix, and do that single branch feature-or-fix well. This way we can ensure proper-steady and audit-able contributions rather than monolithic merge requests that risk going against the philosophy we aspire for.

1. Fork and Clone

Note

Sections of this kind will be written as if you're contributing towards Vulpine Linux, rather than just the current repository, that is because this repository builds into Vulpine Linux but it should still be followed all the same.

We want to start by saying thank you for considering a contribution that aligns with Vulpine Linux's philosophy, whilst we encourage people to follow the wiki, we know you often want a fast answer. This is a low-level, from-scratch system - so contributions should reflect an understanding of how the system is built and why it is built in this way.

Understand that all contributions should be:

• Human-first, where code must be human-written and understood
• Signed at the point of commit
• Have clear explanations in your pull-request, as changes must be well-documented
• Tested before pull-request'd, verify changes work before submitting!

Before making changes, fork the repository and clone it locally, an example of this would be:

git clone https://codeberg.org/YOUR-USERNAME/{REPO}.git && cd {REPO}/

Then create a new branch.

If its a feature (such as adding, updating or changing an existing software) git checkout -b feature/your-feature-name

An example would be: git checkout -b feature/csh-config

If your goal is to work on an issue you should use git checkout -b fix/issue-reference-name

An example would be git checkout -b fix/expand-alias-overflow

Your changes must be made in a dedicated branch (e.g. feature/your-feature-name)

2. Test Your Changes

Once you've made changes, on your branch, please build and test:

./build.sh

Follow the flowchart as a general guide:

flowchart LR
    A[Build-and-run] --> B{Is your implementation working properly?}
    B -->|Yes| C[Great, take a screenshot and write documentation]
    B -->|No| D[Debug and try again]
    C --> E[Push to fork, pull request, supply docs, submit]
    D --> B

Ensure:

• It does ./build.sh cleanly
• Your feature works as intended
• You haven't inadvertently broken something else
• It can be built reliably time-again using ./build.sh

Avoid hard coding anything that risks being re-written by ./build.sh.

3. Pull Request Expectations

• You've made the feature in git checkout -b feature/your-feature-name or similarly if its an issue or fix as issue/* or fix/* on your own fork, not on the main repository.

• You must detail in at least one paragraph (short if you prefer) what your submission is resolving; describe what you changed and why, and how your code functions cleanly. You can keep it simple, but it must be understandable.

If we do not believe you wrote it, or understand it for yourself - it will be rejected.

• Include any relevant logs or screenshots if applicable for documentation purposes.

• Where possible include a reference link or documentation, so that others can learn from you and the project.

"Using auto-ai to make submissions, pushing clearly AI-generated code, repeated low-quality or unreviewed submissions may result in restricted contribution access. We are a human-first endeavour, we understand AI can be found in the IDE through to documentation in real-life and we cannot stop this but the more we minimise it here, in our project, the happier we all are." ~Charlie

You can then push your branch to your fork and open a Pull Request against the main repository ensuring your PR description follows the expectations outlined above, remembering to sign your commit we will reject any that are not signed.

Bare in mind when providing a -m for messaging to keep it short-and-simple for example git commit -m "patch for fixing {issue}", no one wants clunky and excessive messages, we will reject ridiculous or over-wordy messages.

Review Process

All contributions are:

• Reviewed manually
• Tested for stability and compatibility
• Evaluated for alignment with project philosophy

Submissions that cannot be clearly explained or maintained will be rejected. This is true for unsigned commits or those submitted on/to the main repository - it must go through your fork, and Pull Requested. We cannot overstate enough that Vulpine Linux is built step-by-step with intent so contributions should reflect that same mindset and set the bar for other developers to come after. We appreciate strongly well written and proper commits - it matters massively for reference and professionalism both on your part and ours.

Design Philosophy

VPM is intentionally minimal and we aim to follow the Vulpine Linux Philosophy:

• Keep it transparent so others can understand exactly what it does by reading the code
• Stateless and low-complex meaning zero hidden logic
• Every operation should be traceable and audit-able
• Dependency-light means writing in a secure and minimal way

We refuse to add convenience features that obscure how the system works. VPM should do package management simply and clearly.

Support

For support, you can reach out on discord, or InTheMansion irc channels #lobby, or #vulpinelinux.

We strongly suggest reading our wiki before submitting any issues, or checking Discord first, because not everyone has Codeberg and issues might already be known before you open one, it is always worth checking in with the community first.

License

VPM © 2026 by BaronScott Consortium is licensed under Creative Commons Attribution-ShareAlike 4.0 International.

This license applies to VPM as part of the Vulpine Linux ecosystem. All tools and dependencies used retain their original licenses.