# arch4edu: a community package repository for Arch Linux students

> arch4edu is a community repository for Arch Linux and Arch Linux ARM that tries to carry the newest versions of the software college students actually use, with per architecture package trees and a set of scripts for adding, moving and removing packages. It is run by volunteers, and it depends on a separate tool to keep its AUR packages current.

**arch4edu/arch4edu** — Arch Linux Repository for Education

- Repository: https://github.com/arch4edu/arch4edu
- Website: https://arch4edu.org
- Stars: 674 · Forks: 49
- Language: Shell
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/arch4edu-arch4edu

## A repository aimed at one specific audience

arch4edu describes itself as an Arch Linux repository for education, and its tagline is that it makes your Arch Linux better for learning and researching. The introductory paragraph is more precise about what that means in practice: it is a community repository for Arch Linux and Arch Linux ARM that strives to provide the latest versions of most software used by college students.

Two decisions are embedded in that sentence. The first is the audience, and it is narrow. This is not a general purpose third party repository that happens to contain some academic packages; it is a repository whose selection criterion is what a student needs, which in practice means the tools that turn up in a course, a lab or a thesis.

The second is the freshness requirement. The stated goal is the latest versions, not the most stable ones, and that is a real divergence from what an official Arch repository does. Arch itself ships bleeding edge software, and this repository follows the same philosophy, which is why it exists at all: official Arch repositories are organised by what a maintainer considers broadly useful, and specialised scientific and teaching software often does not fit that description even when many people need it.

The supporting infrastructure sits alongside the packages. There is a homepage at arch4edu.org, a wiki with the practical instructions, and a spread of community channels including a Twitter account, a Telegram channel and a Telegram group, a Matrix room and an IRC channel on the Libera network. The channel list is long for a project this focused, which tells you the community is the point as much as the package list.

## Two architecture trees and a shared any directory

The top level of the repository is a packaging layout rather than an application, and reading it tells you how the project is built.

There is an x86_64/ directory and an aarch64/ directory, one per CPU architecture, alongside an any/ directory. The naming follows the Arch Linux package convention where architecture independent content is kept separate from the per architecture trees, and it also appears in the .pacman/ directory, which is the pacman repository configuration rather than a package source directory. A pacman repository needs a database and an index, and a .pacman/ directory is where that metadata lives.

The template/ directory is the other structural piece. Its presence next to the architecture trees and the scripts implies a template from which new package directories are created, and the match-template.sh script sitting at the root alongside move-package.sh, remove-package.sh and smart-add-package.py is consistent with a workflow where adding a package means starting from a template and then moving the result into the right architecture tree.

The two Python scripts, show_aur_dependency.py and smart-add-package.py, are the visible evidence that the AUR is part of the workflow rather than an afterthought. A script that shows AUR dependencies and a script that adds a package automatically both point at the same reality, which is that a large part of the software in this repository originates as a user submitted package in the AUR and is then mirrored here.

That has an important consequence for anyone evaluating the project, and it is the subject of the separate repository mentioned in the readme.

## The AUR dependency is handled by a separate project

The readme links to a project whose title describes exactly what it does: arch4edu/aur-auto-update, a project to automatically update the package on the AUR when there is a new version.

The structure of that arrangement is worth spelling out, because it explains how a volunteer repository stays current. Packages that originate in the AUR are updated there, by the AUR maintainers, and this project automates the detection of a new upstream version and the follow up action in the arch4edu tree. The scripts in this repository are the manual counterparts, the ones a human runs when the automation has not covered a case or when a package needs attention.

There is a practical lesson in that separation. A repository that mirrors AUR content inherits the AUR's review model and its update behaviour, and a mirror that did not track upstream would present users with stale versions of exactly the software the project promises to keep current. Automating the mirror is the answer to the mirror problem, and the readme points at the tool that does it.

For a user, the practical question is what happens when a package in the repository is broken. The answer is the community channels, and there are several of them, which for a project maintained by volunteers is the mechanism that has to work well.

For a potential packager, the wiki page on adding a package is the entry point, and the scripts in the root are the tools. The two other wiki pages, one on adding arch4edu to your Arch Linux and one on adding a package to arch4edu, are the two tasks the project expects people to want to do.

## What a pacman repository actually contains

It is worth being explicit about what a repository of this kind is, because the word repository covers two different things in the Arch world.

There is the repository that pacman talks to, which is a set of package files, a signature and an index database that the client downloads and verifies. That is what the .pacman/ directory is for, and it is generated rather than authored.

And there is the source of that repository, which is the directory tree in this project. The x86_64/ and aarch64/ directories hold one directory per package, each containing the PKGBUILD that tells pacman how to build it, along with any patches and auxiliary files. The any/ directory holds the packages that do not depend on a processor architecture, and the template/ directory holds the starting point used to create a new package directory.

A PKGBUILD is a shell script, and that is the origin of the repository's primary language being Shell. The script names the package, its version, its licence, its dependencies and its install steps, and pacman runs it to build the binary. The move-package.sh, remove-package.sh and match-template.sh scripts in the root are repository maintenance helpers operating on that structure, while the Python scripts handle the parts that need to parse or fetch something.

The practical consequence for a user is that adding this repository means pointing pacman at a URL and trusting a signing key, and for a packager it means writing a PKGBUILD that produces a package the same way every other Arch package does. The bar for a package to be usable here is therefore the same bar as anywhere else in the distribution, which is what keeps the repository usable.

## An active repository with no releases and no stated licence

The maintenance facts are simple and mixed.

The repository is not archived, the default branch is master, and the last push was on 2026-10-22, the day before the current date. The activity is therefore current rather than historical, which for a package repository is what matters, because a package set that is not being touched is a package set that stops working with a rolling release distribution.

There are no GitHub releases, and that is the correct model for a pacman repository. A release implies a versioned artefact that someone downloads, and this repository is not that. It is a set of directories that pacman reads over a protocol, and the pacman database and the per architecture trees are updated in place. The versioning lives in the package versions themselves and in the AUR packages they mirror.

The licence is recorded as unknown, and there is no licence file among the top level entries, which run from.github/ and.gitignore through the.pacman/ directory, the two architecture trees, the any/ directory, the scripts and the template directory, ending with the project README. Under the default copyright rules, that means the packaging files here carry no explicit permission to copy or redistribute.

That is a slightly odd position for a repository whose entire purpose is redistribution of other people's software, and it is not the fault of the licences of the packages themselves, which are their own business. For a user adding this repository to their machine, the practical effect is nil, because they are fetching packages, not copying the repository. For anyone who wants to run their own mirror, it is a question to raise with the maintainers.

The primary language of the repository is recorded as Shell, which fits a repository whose own content is mostly packaging metadata and a handful of helper scripts rather than source code.

## Conclusion

arch4edu suits an Arch Linux user in education who wants recent versions of teaching and research software without building it themselves, and it suits a packager willing to maintain a package. It does not suit someone who needs a supported distribution channel with a security team behind it, since it is a volunteer repository with no releases, no stated licence and no promise of build reproducibility. Before adding your machine to it, read the wiki pages on adding arch4edu and on adding a package, and check the AUR auto update project, because a repository whose packages come from the AUR depends on something outside its own control staying current.

## FAQ

### What is arch4edu?

It is a community repository for Arch Linux and Arch Linux ARM that strives to provide the latest versions of most software used by college students, with the stated aim of making Arch Linux better for learning and researching.

### How do I add arch4edu to my Arch Linux system?

The repository points to a wiki page titled Add arch4edu to your Arch Linux, which covers the setup, and a second wiki page titled Add a package to arch4edu for contributing. The package trees themselves are split into x86_64, aarch64 and any directories, with the pacman repository configuration in the .pacman directory.

### How does arch4edu keep its AUR packages up to date?

Through a separate project, arch4edu/aur-auto-update, which automatically updates the package on the AUR when there is a new version. The scripts in the repository, including show_aur_dependency.py and smart-add-package.py, are the manual counterparts for the cases the automation does not cover.

### Is arch4edu still active?

The repository is not archived, the default branch is master, and the last push was on 2026-10-22. There are no GitHub releases, which is the normal model for a pacman repository whose package trees are updated in place rather than versioned as downloadable artefacts.

## Sources

- [arch4edu/arch4edu on GitHub](https://github.com/arch4edu/arch4edu)
- [Issues](https://github.com/arch4edu/arch4edu/issues)
- [Project website](https://arch4edu.org)
- [README](https://github.com/arch4edu/arch4edu/blob/master/README.md)

---

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