This is a non-exhaustive list of general things to remember and maintainability practices for keeping a custom repository as quality as possible. In general, we (pacstall devs) would love for you to contribute to our repository but there are times where that simply isn't doable, be that for custom distro packages, business deployment setups, or even sailing the high seas 🏴‍☠️. I think you're starting to get a common theme: complete control over the repository.

There are essentially three ways to make a repository. You are fine to do any of these, but make sure you understand what each does before committing to one.

We have set up our repository so that you can simply create a template, which will essentially squash all of our repository's git history together, meaning you will get a clean and complete copy of our repository, ready for you to change. Note that this will carry over all of our packages into your repository, but you are encouraged to remove those in the next commit.

This is probably the simplest method of making your repository, but it has a couple catches:

1. You will be keeping our repositories packages in your own (which you likely don't want).
2. It will clutter your repositories git history.
3. It might have the occasional merge conflict in packagelist.

On the plus side, you will rarely deal with merge conflicts while still being able to pull from our resources used for maintaining the repository itself without having to go out and grab those changes on your own.

We do not recommend this for anyone who wants to create a repository, but we leave it here for completeness. Below is a graph of the required files needed for pacstall to operate on your repository correctly:

package-repository/
├── packages/
│   ├── example-package1/
│   │   ├── example-package1.pacscript
│   │   └── .SRCINFO
│   └── example-package2/
│       ├── example-package2.pacscript
│       └── .SRCINFO
├── scripts/
│   └── srcinfo.sh
├── distrolist
├── packagelist
└── srclist

Where example-package{1,2} are obviously optional, but included as an example for how pacscripts must be named along with the required .SRCINFO files. We also highly recommend using pre-commit to make sure committers updated .SRCINFO, packagelist, srclist, etc automatically when they commit. We also highly recommend that you use our repository's pre-commit file, which ensures a consistent style, and automatically updates the proper files when needed.

Since your repository is (most likely) uncoupled from our repository, your packages and repository will not be updated by the time a new pacstall release comes out, which may entail breaking changes.

The first major thing that you should keep in line with our repository are CI changes, which fall into two categories:

1. GitHub specific changes (workflows, issue templates)
2. Agnostic changes

If you are hosting your repository on GitHub (or anything that consumes GitHub action workflows), you should pull both, but if you only care about keeping pacstall satisfied, only pull in agnostic changes.

You can find these types of commits by cloning our repository, and grep the commit messages for ci, or if you know Conventional Commits, the type is ci.

The next biggest thing to do is to monitor what commits come into pacstall, specifically breaking changes. You can get a list by running this command from an up to date repository of https://github.com/pacstall/pacstall:

git log $(git describe --tags --abbrev=0)..HEAD --oneline | grep '!'

And check for breaking changes, which are denoted at the start of commits either as:

1. feat!:
2. feat(*bla*)!

Basically anything that has an exclamation mark before the colon is a breaking change, and you should read the commit to make sure you understand what this change will do to pacstall and how to prepare your repository for the changes.