Debian 生态系统与 FreeBSD 生态系统在软件包维护方面的差异，（杰西·史密斯）

[jingyue]

评价（由 杰西·史密斯）（谷歌翻译，仅供参考），

软件包没有流入Debian

大约五年前，我花了一个月的时间使用Unity 7桌面。总体而言，这是一个很好的经验，不久之后，我决定一次性采用Unity作为我的主要桌面环境。在运行Ubuntu的时候使用Unity很顺利，但是当我切换到另一个基于Debian的发行版时，Unity不再可用。 Canonical已经为他们的Ubuntu发行版本开发并打包了Unity，而这些软件包从来没有回到Debian的上游。

大约一年前，我正在尝试在Android手机上安装UBports。当时我不得不运行一个名为ubuntu-device-flash的工具来把我的新操作系统放到手机上。但是，尽管这个工具对于Ubuntu用户是可用的，但是对于像我这样的表兄弟Linux Mint Debian Edition来说，这个工具是不可用的，尽管这两个工程都是从Debian派生的。

一年多前，我正在试用Lumina桌面。在运行SparkyLinux的时候，安装Lumina的时候很容易，因为它已经被打包，并且在官方的仓库里。但是，几个月后，我转换到运行MX Linux作为我的工作站分配和Lumina不再可用。 SparkyLinux和MX Linux都基于Debian和密切相关，但MX没有Sparky的Lumina包。而且，就此而言，Sparky无法访问MX的自定义配置工具。这是MX-Tools和Lumina软件包没有回到Debian上游的结果。

大约在2018年初，我正在试验两种基于Debian的发行版，MX Linux和deepin。我真的很喜欢deepin的桌面环境，我喜欢使用MX的配置工具。尽管这两个项目都是Debian的直接后代，但是MX没有deepin的桌面软件包，deepin也没有使用MX的管理工具。

在这一点上，模式可能很清楚。基于Debian的发行版通常使用他们自己的工具和软件包，这些工具和软件包在官方的Debian软件库中不存在。对于开发基于Debian的项目的开发人员来说，要么将其软件包含在Debian本身，要么是障碍要么缺乏动力。这是一个耻辱，因为Debian有很多的孩子，在撰写本文时有超过100个主动发行。虽然所有这些孩子使用相同的软件包格式，图书馆和软件包管理者，但他们经常被阻止使用由兄弟项目开发的软件。

我怀疑问题的一部分是开发人员已经忙于自己的软件工作，并没有觉得有时间上传他们的软件包到Debian。也许没有太多的动机。开发人员为其发行版的用户制作软件，而在将其工作扩展到其他基于Debian的项目中可能看不到多少好处。兄弟姐妹项目之间甚至会有友好的竞争意识，降低了分享包装的动力。

另一个分享软件包的障碍是，我认为这个过程涉及将软件加入Debian的官方软件库。关于如何成为Debian贡献者的Debian wiki上的页面大约有100行。那是在创建安全密钥之前，阅读开发者文档或者通过软件指南，社交契约和寻找导师。我所说的是成为Debian开发人员是一个漫长的过程，我认为这不利于软件开发人员将他们的工作重新投入到更大的Debian系列中。

我将这个情况与Debian的孩子以及他们的各种软件包与FreeBSD的家庭进行了对比。 FreeBSD有十几个主动维护的孩子。虽然Debian系列树的不同分支机构通常具有独特的软件包，但FreeBSD系列的成员通常没有一个项目所特有的软件包。从事基于FreeBSD的项目的团队肯定会制作自己的软件。例如，TrueOS创建了Lumina和GhostBSD开发了自己的图形化网络管理器。交换扩展器守护进程由TrueOS发展而来。与SysAdm远程管理守护程序一样，Octopkg程序包管理器已启动以用于下游项目。这些新包中的每一个都是由不同的项目开发的，然后再回到FreeBSD软件仓库。这意味着所有基于FreeBSD的项目都可以使用这些软件。

据推测，从事基于FreeBSD的项目的工作人员有同样的动机来关注自己的工作，而不是花费精力去帮助其他项目。而且，大概从事这些项目的人不一定会花费大量时间帮助他们竞争（即其他基于FreeBSD的操作系统）。尽管如此，FreeBSD生态系统似乎还有更多的共享，更多的异花授粉，而不是Debian系列。我怀疑有一个很大的原因是需要将软件放入FreeBSD的仓库。

希望将自己的工作纳入FreeBSD的人通常只需要执行两个步骤：注册一个免费帐户来访问FreeBSD的问题跟踪器，并提交一个问题，要求添加一个新的包，包的配方（称为端口）连接。假设新的港口建立得当，那通常涉及所有的工作。 FreeBSD的开发者可能会要求稍微调整一下端口的风格和正确性，否则作者的工作就完成了。没有安全密钥生成，没有社会契约来阅读，没有必要的指导，开发人员只是发送他们的代码，这是看过去（通常）被接受。这使得在FreeBSD中添加软件的时间几乎与在Arch Linux的Arch User Repository中获得新的软件包一致。

我花了大约相同的时间在Debian和FreeBSD社区，我认为虽然两者都是世界级的，稳定的操作系统，但FreeBSD团队已经找到了一种更好的方式来鼓励衍生项目将其作品提交给父项目操作系统。我认为，如果从下游发行软件到上游软件更容易获得软件，Debian和基于Debian的发行版将会受益匪浅。即使只是进入半官方，社区维护的资料库类似于用户资源库。开发人员在基于Debian的项目上做了很多很好的工作，用户从其他基于Debian的发行版中获取软件包应该会更容易，因此他们不需要切换发行版或编译自己的软件包就可以获得所需的功能。


原文地址：

https://distrowatch.com/weekly.php?issue=20180212#news

原文（英文）：

Opinion (by Jesse Smith)

Packages not flowing upstream into Debian

About five years ago I spent a month using the Unity 7 desktop. Overall, it was a good experience and, shortly after that, I decided to adopt Unity as my main desktop environment for a time. Using Unity went well while I was running Ubuntu, but when I switched to another Debian-based distribution, Unity was no longer available. Canonical had developed and packaged Unity for their Ubuntu distribution only and the packages had never made their way back upstream to Debian.

About a year ago I was experimenting with installing UBports on an Android phone. At the time I had to run a tool called ubuntu-device-flash to get my new operating system onto the phone. But while this tool is available for Ubuntu users, it was not available to people like me running its cousin, Linux Mint Debian Edition, even though both projects are derived from Debian.

A little over a year ago I was experimenting with the Lumina desktop. While running SparkyLinux, it was easy to install Lumina as it was packaged and in the official repositories. However, some months later I had switched to running MX Linux as my workstation distribution and Lumina were no longer available. Both SparkyLinux and MX Linux are based on Debian and closely related, but MX doesn't have Sparky's Lumina package. And, for that matter, Sparky does not have access to MX's custom configuration tools. This is a result of MX-Tools and Lumina packages not making their way back upstream to Debian.

Around the start of 2018 I was experimenting with two Debian-based distributions, MX Linux and deepin. I really liked deepin's desktop environment and I enjoyed using MX's configuration tools. Once again, despite the two projects both being direct descendants of Debian, MX did not have deepin's desktop packages and deepin did not have access to MX's administration tools.

At this point the pattern is probably pretty clear. It is quite common for Debian-based distributions to feature their own tools and packages which do not exist in the official Debian repositories. It seems there is either a barrier or a lack of motivation for developers working on Debian-based projects to get their software included in Debian itself. Which is a shame, because Debian has a lot of children, over 100 active distributions at the time of writing. While all these children use the same package formats, libraries and package managers, they are often prevented from using software developed by their sibling projects.

I suspect part of the problem is developers are already busy enough working on their own software and do not feel they have time to upload their packages to Debian. Perhaps there is not much motivation either. Developers make software for their distribution's users and probably do not see much benefit in spreading their work to other Debian-based projects. There may even be a sense of friendly competition between sibling projects which reduces the motivation to share packages.

Another hurdle to sharing packages though is, I think, the process involved in getting software into Debian's official repositories. The page on Debian's wiki which gives a brief summary on how to become a Debian contributor is about 100 lines long. That's before we get into creating security keys, reading the developer documentation or going through the software guidelines, social contract and finding a mentor. What I'm saying is it is a bit of a long process to become a Debian Developer and I think it discourages software developers from contributing their work back into the larger Debian family.

I contrast the situation with Debian's children and their variety in packages with FreeBSD's family. FreeBSD has around a dozen actively maintained children. While it is common for different branches of the Debian family tree to feature unique software packages, members of the FreeBSD family usually do not have packages unique to one project. The teams working on FreeBSD-based projects certainly make their own software. For instance, TrueOS created Lumina and GhostBSD developed their own graphical network manager. The swap extender daemon grew out of TrueOS. The Octopkg package manager was started for a downstream project, as was the SysAdm remote administration daemon. Each of these new packages, while developed by separate projects, made their ways back into the FreeBSD software repository. Which means all FreeBSD-based projects can make use of these pieces of software.

Presumably people working on FreeBSD-based projects have the same incentives to focus on their own work, rather than put effort into helping other projects. And, presumably people working on these projects do not necessarily want to spend a lot of time helping their competition (ie other FreeBSD-based operating systems). Still, there seems to be more sharing, more cross-pollination, in the FreeBSD ecosystem than there is in the Debian family. I suspect a big reason for the difference is in the steps required to get software into FreeBSD's repository.

People looking to get their work included into FreeBSD often just need to perform two steps: sign up for a free account to access FreeBSD's issue tracker, and submit an issue asking to have a new package added, with the package's recipe (called a port) attached. Assuming the new port builds properly, that's often all the work involved. A FreeBSD developer may ask for the port to be tweaked a little for style and correctness, but otherwise the author's work is done. There is no security key generation, no social contract to read, no required mentorship, the developer simply sends in their code, it's looked over and (usually) accepted. This puts adding software to FreeBSD approximately on par with getting new packages accepted into Arch Linux's Arch User Repository.

I have spent approximately the same amount of time in the Debian and FreeBSD communities and I think, while both are world-class, stable operating systems, the FreeBSD team has found a better way of encouraging derivative projects to submit their work back to the parent operating system. I think both Debian, and distributions based on Debian, would benefit a lot if it were easier to get software from downstream distributions back upstream to Debian. Even if only into a semi-official, community maintained repository similar to the Arch User Repository. There is a lot of good work being done by developers working on Debian-based projects and it should be easier for users to get packages from other Debian-based distributions so they don't need to either switch distributions or compile their own packages to get desired features.