Void Linux Lost 113 Packages Because One Rule Banned AI Text

Void Linux is an independent distribution with no corporate parent and a thin maintainer bench. In one weekend it lost the owner of 113 packages over an argument about who, or what, wrote a comment on a pull request.

The AI rule was never vague, and it covered prose

Void Linux publishes a contribution policy that covers generative AI. Every contribution must originate from a human and be understood by that human. AI tools are allowed for research and learning. Every use of an AI tool must be disclosed. The policy names code, documentation, issues, security reports, pull request descriptions and comments, so it reaches prose and not only patches. It also bans AI review tools inside pull requests. Only AI-assisted translation gets a pass.

The trigger was ordinary. Maintainer Andrea Brancaleoni opened a package update for Go 1.27.1 and posted a comparison of the 1.26 to 1.27 upgrade impact. A second maintainer asked what produced the comparison. Brancaleoni answered with his usual setup, the GLM-5.3-Flash model driven through OpenCode. That answer broke the policy twice. The text had been generated, and the tool use had not been declared up front.

Brancaleoni said the comparison was accurate and that he stood behind it. The other maintainer replied that authorship was the point, not comprehension. Brancaleoni gave a thumbs up and orphaned every package under his name.

Orphaning 113 packages is a quiet kind of outage

An orphaned package is not deleted. It loses its maintainer. Nobody is assigned to watch upstream releases, rebuild when a dependency moves, or patch the next vulnerability. The package keeps installing for months. Then a vulnerability lands and there is no owner. The 113 package list is not trivia either. It includes Kubernetes, etcd, flannel, docker-cli, docker-gc, docker-gen, moby, Terraform, Terragrunt, Packer, Alacritty, Hugo and virt-manager. Those are the packages a Void user installs to run containers, clusters and infrastructure as code. Phoronix reported the orphan sweep on September 12.

Void now needs volunteers to adopt all of them. Adoption is not a click. It takes a maintainer who knows the software, understands the packaging system and is willing to own future breakage. Kubernetes and Terraform will attract attention. A small package such as fcron or mfoc may wait a long time.

Open source is splitting on the same question

Void chose the strictest line. Other projects chose the looser one. The Kubernetes project published an AI policy in June that allows AI-assisted contributions when the contributor discloses the tooling and takes responsibility for the result. The Linux kernel allows AI code in the same spirit, with the contributor accountable. Debian held a vote and allowed LLM-generated code. The Void Linux AI policy points the other way, and it is enforced.

Both rules cost something. A ban protects authorship and review quality, and it can push away volunteers who have wired an assistant into their daily work. A permissive rule keeps contributors and accepts a heavier review burden. Void picked clarity and paid for it with 113 packages in a weekend.

For platform teams the lesson is practical. Before you depend on a package, check whether it has an owner. A build that works today says nothing about who will respond when the upstream release breaks it. Maintenance status is the real support contract, and it costs nothing to look.

Related reading. We looked at how AI-assisted attack campaigns are compressing the patch window, at what auditors actually ask for in a supply chain review, and at why agent rule files deserve the same review as code.