I write to formally and forcefully express deep concern about the deletion request filed for the AUR package based on portable sandboxing framework and, more broadly, the recent tendency to remove or challenge “portable” and sandboxing‑oriented packages despite clear Arch Wiki guidance permitting legitimately differentiated builds. This is not a minor procedural dispute: it affects real users, real workflows, and the ability of volunteer contributors to safely extend the Arch ecosystem.

Context and immediate facts

On 1 Sep 2025, oech3 filed a deletion request for visual‑studio‑code‑portable claiming it was “Duplicated with visual‑studio‑code‑bin. Personal sandbox config should be covered at Arch wiki.”
Maintainer Kimiblock Moe objected (2 Sep), noting the package’s practical value: monitoring background processes, prohibiting discrete GPU wakeups, and providing sandboxing convenience.
On 7 Sep 2025 the deletion request was accepted by Muflone with the rationale that “almost any package can be sandboxed in some way, this is not a reason to having duplicated packages on AUR for everything.”
The Arch Wiki’s AUR submission guidelines explicitly permit packages that differ from official ones by enabling additional features, applying patches, or shipping alternate configurations, provided the pkgname expresses that difference and conflicts are declared where appropriate. The guidelines even give examples (e.g., screen-sidebar) demonstrating this accepted practice.

The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Check the official package database for the package. If any version of it exists, do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then please file a bug report.

Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones.
Make sure the package you want to upload is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.
There are actual users of portable‑based packages — visible from community engagement such as stars and activity on related GitHub repositories — demonstrating concrete, ongoing demand for these variants.

Why this decision is wrong and harmful

It contradicts the Arch Wiki guidance the AUR moderation cites. The Arch Wiki explicitly permits packages that enable extra features, apply patches, or ship alternate configurations — provided the pkgname reflects the difference and conflicts are declared when appropriate. Portable packages do precisely this: they alter runtime behavior and security posture, not merely republish the same binaries.
Portable packages provide concrete, demonstrable user value. Users rely on portable variants for privacy, security, and usability improvements (e.g., background portal handling, D‑Bus filtering, process management, hybrid GPU workarounds). This is evidenced by user adoption and activity on related projects. Deleting these packages removes convenient, trusted options for users who do not want or cannot configure sandboxes by hand.
The “anything can be sandboxed” rationale is too broad and collapses a nuanced distinction. The AUR’s role is to host meaningful variations that satisfy real user needs. Arguing that a capability exists in principle on the system does not justify removing packaged, maintained variants that make that capability accessible, safe, and reproducible for ordinary users.
The decision was applied without transparent, itemized reasoning showing why visual‑studio‑code‑portable failed to meet AUR rules. The community needs to see concrete points of non‑compliance when a package is removed, especially when the maintainer has explained practical benefits and the package follows the naming convention that signals difference.

Why portable variants are functionally distinct

Portable/sandbox packages are not trivial duplicates. They change how applications interact with the host and supply curated, security‑oriented defaults and runtime controls. Notable, concrete differences commonly provided by portable variants:

Background Portal support for safer standardized access.
Wayland security context support and PipeWire security contexts when needed.
Access control that restricts file/namespace visibility of the app.
Shared‑files mechanism for apps without portal support.
D‑Bus filtering to reduce attack surface and block potentially dangerous messages.
Process management tools to monitor and terminate application processes.
Packaging ease: portable often requires only a config file, making it simpler for packagers and maintainers.
Storage efficiency over Flatpak by using the host runtime.
Hybrid GPU workarounds preventing unnecessary discrete GPU wakeups.
Curated, safe portals and blocked unsafe ones by default.

These are not hypothetical features; they materially change runtime behavior and affect security, privacy, and energy usage for end users.

Requested remedies and policy changes

Reopen and transparently review deletion #75776 and all other portable-based packages. If the moderation team believes visual‑studio‑code‑portable and others violate a specific AUR rule, state the exact rule and itemize how the package fails to comply. If no such rule is violated, restore the package.
Publish a clear policy clarification on portable/sandbox packages. Define what constitutes an acceptable “extra feature/patch/config” versus an unacceptable trivial duplication. Include examples (e.g., sandboxed vs. upstream config, naming conventions, when conflicts=(‘…’) is required).
Require deletion decisions to include a short, public justification comparing the package to the alleged duplicate (feature-by-feature). This prevents ambiguous, principle‑only rejections like “anything can be sandboxed.”

Closing

Arch Linux and the AUR have thrived because volunteers can publish and maintain packaging variants that serve diverse needs. Removing portable, sandboxing, or privacy‑focused packages on an overly broad “duplication” premise undermines that mission. The deletion of visual‑studio‑code‑portable appears to be such a case: the package provided real, documented differences that help users and align with current Arch Wiki guidance.

I request transparent reconsideration of all deletions towards all portable based packages, clear publication of the policy rationale, and structural improvements to prevent similar, opaque removals in the future.

If you want the full suite of portable sandboxes, please either use [archlinuxcn] for FOSS only apps, or portable-arch for full suite of supported apps. You can also contribute to the latter repository, and use it just like AUR thanks to paru.