现在官方商店的定位就很尴尬，既不能保证打包质量，又没有足够的社区参与度。在进行彻底的改革之前，保证打包质量就是句空话。建议在商店专门设一个由社区用户负责维护的分区，社区用户可以自由上传软件包，认领无人维护的软件包，以及对自己负责的软件包进行全权维护。官方在用户维护区发现的高质量软件包，只要官方愿意维护，随时可以从用户维护区转入官方区；官方无力维护的软件包，也可以丢到用户维护区等人认领。如果人力物力不太充裕，可以考虑和星火社区合作；如果有足够的资源，最好还是部署一个 open build service 或者类似的公共构建服务，让打包流程公开透明，这样更有利于保障打包质量。

AUR 是不允许重复打包同一个软件的，除非有充分的理由发布一个修改版。这一点也可以借鉴。

或者完全做成 OBS 的那种模式，每个社区打包者自己开一个仓库，然后用户可以选择添加信任的打包者的仓库，并安装其中的软件。添加仓库并安装软件在 openSUSE 上是可以一键完成的，这一点对于不熟悉命令行的用户来说非常方便。但这样的话，弃置软件包的流程可能又要重新设计了

Deepin官方应用商店能否与星火商店有个明确的协议：官方有权把星火商店比较成熟的符合规范的软件转入官方应用商店，社区成员积极反馈在使用软件过程中发现的问题以利完善

现在有打包规范了，大家都按照打包规范走，官方做好筛选，合格的上架应用市场。

或者开悬赏任务，提高维护人员的参与积极性。

“以用户为中心”并不只是一句口号而已，我不认为 deepin 是一个以用户为中心的发行版，也不认为 deepin 的目标是成为这样的发行版。

什么叫“以用户为中心”？注意我这里说的不是“以用户为中心的设计理念”，那和 Linux 发行版的“以用户为中心”不是一回事。就以我用的 Arch Linux 为例：没有自作主张的预装和配置，只提供一个易于定制的基础系统，把选择权留给用户，这是在终端层面的以用户为中心；官方最大的软件仓库 [community] 的维护者称为 Trusted User，全球最大的 Linux 发行版打包脚本仓库叫做 Arch User Repository（也由 TU 管理，但允许任何用户上传打包脚本），让用户根据自己的需要通过 Arch Build System 自行打包，并轻松地分享给其他用户，这是社区层面的以用户为中心。而 deepin 作为一个商业化、成品化的发行版，本质上就不可能“以用户为中心”。

不过 Arch 的社区运作模式并非不能为 deepin 所借鉴。比如说，现在商店里的很多软件包都缺乏维护，不少软件包是过期的。因此，需要有更完善的机制来鼓励维护者积极跟进上游的更新。Arch 的做法其实也很简单，就是让任何用户都可以在软件包上打一个显眼的过期标记。另外，一个易于使用的软件包构建系统无疑会降低参与打包维护的门槛——不需要 Debreate 那样的图形化工具（恰恰相反，我觉得 Debreate 很难用），而是像 PKGBUILD 和 makepkg 那样格式统一的打包脚本和易于复现的打包方式。

好像有人做了一个叫 makedeb 的东西？

https://mpr.hunterwittenborn.com/

是否类似？

“以用户为中心”并不只是一句口号而已，我不认为 deepin 是一个以用户为中心的发行版，也不认为 deepin 的目标是成为这样的发行版。

什么叫“以用户为中心”？注意我这里说的不是“以用户为中心的设计理念”，那和 Linux 发行版的“以用户为中心”不是一回事。就以我用的 Arch Linux 为例：没有自作主张的预装和配置，只提供一个易于定制的基础系统，把选择权留给用户，这是在终端层面的以用户为中心；官方最大的软件仓库 [community] 的维护者称为 Trusted User，全球最大的 Linux 发行版打包脚本仓库叫做 Arch User Repository（也由 TU 管理，但允许任何用户上传打包脚本），让用户根据自己的需要通过 Arch Build System 自行打包，并轻松地分享给其他用户，这是社区层面的以用户为中心。而 deepin 作为一个商业化、成品化的发行版，本质上就不可能“以用户为中心”。

不过 Arch 的社区运作模式并非不能为 deepin 所借鉴。比如说，现在商店里的很多软件包都缺乏维护，不少软件包是过期的。因此，需要有更完善的机制来鼓励维护者积极跟进上游的更新。Arch 的做法其实也很简单，就是让任何用户都可以在软件包上打一个显眼的过期标记。另外，一个易于使用的软件包构建系统无疑会降低参与打包维护的门槛——不需要 Debreate 那样的图形化工具（恰恰相反，我觉得 Debreate 很难用），而是像 PKGBUILD 和 makepkg 那样格式统一的打包脚本和易于复现的打包方式。