Here’s the thing: Fedora’s Engineering Steering Committee (FESCo) didn’t just vote to retire Deepin packages; they slammed the door shut. The verdict, a unanimous +7 at their May 19 meeting, means no Deepin components are coming back unless they face a brand-new, rigorous review process. This isn’t a minor hiccup; it’s a definitive statement on security and commitment.
This dramatic eviction is the culmination of over a year of mounting concerns, sparked initially by a damning report from openSUSE’s security team in May 2025. They’d already pulled Deepin packages after discovering serious flaws. The deepin-file-manager daemon had D-Bus interface issues, and both deepin-api and deepin-system-monitor were found to be using deprecated, insecure Polkit authentication methods.
Suddenly, Fedora’s own house looked decidedly messy. Adam Williamson of the Fedora QA team raised a crucial question: if SUSE flagged these problems, what was Fedora doing? The answer, it turns out, was alarming. Fedora had been shipping these packages with virtually no meaningful security review. Worse, the project’s own package review guidelines were found to be woefully inadequate, lacking any clear requirements, tools, or instructions for reviewers to even consider security implications. And in a particularly telling detail, some security-related guidelines that did exist had been deleted years prior.
Why This Matters for Open Source Governance
This isn’t just about one desktop environment. It’s a stark illustration of how the very architecture of open-source project governance can falter. When security is an afterthought, or when the review process itself is under-resourced and ill-defined, the entire ecosystem suffers. The fact that Fedora lacked basic checks for packages that are now proven to be insecure reveals a systemic weakness that many distributions likely share to some degree.
By the time FESCo made its final decision, the Deepin packages were already on life support. Core components had been failing to build across multiple Fedora releases (42, 43, and 44). The desktop environment itself had been kicked out of Fedora spins and fedora-comps months earlier, not due to a policy change, but because essential packages simply refused to compile.
The Special Interest Group (SIG) responsible for Deepin in Fedora, the DeepinDE SIG, had withered. Key maintainers had moved on, leaving a significant workload on a skeletal crew. Zamir Sun, a former coordinator for the SIG, confirmed this in an email to FESCo, stating:
To make a long story short, all the initial packagers of the Deepin DE packages(namely felixonmars, mosquito(no longer with Fedoraproject) and cheeselee in FAS, and me as the coordinator) are being too busy for the vast amount of work in maintaining DeepinDE. And we never got active packagers to take the effort so we have to see it going away from Fedora.
This left Felix Wang (topazus) as the sole individual nominally responsible for the packages. However, Wang had seemingly gone dark, ignoring bug reports, maintainer pings, and direct emails. The pattern was clear: whenever Fedora’s automated build failure policy orphaned a package, Wang would simply reclaim it, offering no fixes. It’s a dereliction of duty that directly compromises the integrity of the distribution.
Is This the End for Deepin on Fedora?
FESCo gave the Deepin packagers a formal outreach on May 5, with a four-week window for a substantive response. When silence was the only reply, the committee acted decisively. Release Engineering is now under strict orders not to reinstate any of these packages without a proper, fresh review. So, for now, Deepin’s chapter on Fedora is closed. A comeback is theoretically possible if a dedicated team steps up and navigates the full review gauntlet, but given the current state of affairs and the project’s past neglect, such a scenario feels like a long shot.
This entire episode serves as a stark, data-driven reminder for all open-source projects. The convenience of readily available packages must never, ever come at the expense of rigorous security vetting and sustained maintenance. When those pillars crumble, the trust users place in a distribution erodes, and frankly, that’s a risk no major distro can afford to take.
