debian在铁锈coreutils上运行

TLDR：Rust / Coreutils（https://github.com/uutils/coreutils/）现在可以在Debian中获得，足以通过GNOME启动Debian，安装前1000个包，构建Firefox，Linux内核和LLVM / Clang 。即使我写了100多个补丁来实现这一点，对于许多其他用例来说，它可能是一个颠簸的骑行。它也是一个学习锈的一个明显的项目。查看好的第一个错误列表。

即使我每天在Mozilla看到Rust Code，我也在寻找一个实际的个人项目（即，这是一个＆＃39; t一个mozilla项目），在各种Covid锁定期间学习生锈。

我开始为锈病开发的替代Coreutils做出贡献。该项目旨在提出替换基于C基GNU Coreutils的替代，我想评估是否可以使用常规Debian。与几年前的Clang.debian.net类似于我用Clang.Net所做的事情（使用Clang而不是GCC重建Debian Archive）。

我希望大多数读者知道Coreutils是什么。它是执行简单操作的一组程序（复制/移动文件，更改权限/所有权等）。即使某些命令来自70年代，它们也在Linux，UNIX和MacOS的基础上。虽然可以找到不同的实现，但他们正在尝试在参数，选项等方面保持兼容。这是Coreutils的实施并不不同！

如果您想了解有关UNIX历史的信息，我推荐这款伟大的CoreCursive Podcast与Brian Kernighan。

虽然很多人为这个项目做出了贡献，但很多都被遗忘：

运行GNU Coreutils Testsuite时的许多失败（141测试通过613） - 一些微不足道的修复，有些其他更难的......从锈版开始的好方法！

包装在Debian ISN＆＃39; t一个微不足道的甚至简单的任务。它需要独立上传存档中的所有依赖项。凭借其新的生态系统和小型箱子，锈蚀，这项任务明显困难。

对于Debian / Ubuntu用户，要了解包装这些应用程序的复杂性，只需运行Debtree --Build-Dep Rustutils | DOT -TSVG＆GT; Coreutils.svg（应该是1米）。

由于它是＆＃39; t生产准备好，Rust-Coreutils与Coreutils平行安装。此包不会替换GNU / Coreutils文件（尚未？），新文件安装在/ usr / lib / cargo / bin /。

为实现这一目标，因为我知道我可能会打破几次图像，我创建了一个新的项目，以快速安装一个完整的debian与pxe和preeseed。

然后，在系统上建立和安装Coreutils（是的，是丑陋的 - 在家里不这样做）：

第一个惊喜，与旧init.d init系统不同，因为systemd没有依赖一系列脚本（它主要写在c），替换coreutils没有影响。因此，我在启动过程中没有经历任何问题

Debian软件包在安装后脚本（存储在/ var / lib / dpkg / info / *）上依赖很多，以完成和配置包。它们（差不多？）都使用/ bin / sh（或/ bin / bash）来执行这些操作。他们强烈地调用Coreutils应用程序。

使用丑陋的脚本，我们可以逐个测试1000个最流行的包的安装。

对于某些选择缺乏支持，可以很容易地识别出大量问题。

以下是我必须实施的大多数修复程序列表，以便进行此计划工作：

安装使用/ dev / null支持使用/ dev / null作为源文件设置libreoffice-common（1：6.1.5-3 + deb1d10u6）...安装：错误：安装：无法安装'/ dev / null'到' /etc/apparmor.d/local/usr.lib.libreoffice.program.oosplash'：源路径不是现有的常规文件，对生锈本身的限制https://github.com/rust-lang/rust/issues/ 79390

＆＃34;安装foo.txt bar.txt＆＃34; didn＆＃39; t工作 - https://github.com/uutils/coreutils/pull/1644安装：错误：目标'bar.txt'不是目录

ls非现有文件不是＃39; t返回错误代码。 ＆＃34;如果ls＆＃34;由某些脚本使用 - https://github.com/uutils/coreutils/pull/1654

其中一个问题是安装-d / tmp / foo无法执行两次（而第二次运行GNU版本WOWSN＆＃39; T如果已经存在，则触发错误） - https：//github.com/uutils/ Coreutils / Pull / 1641

由于Firefox主要依赖于Python作为构建系统，它顺利进行。我没有遇到任何问题。

我注意到它的唯一不相关的问题是apt-key被破坏，因为脚本依赖于mktemp的错误选项。

在非现有Symlink目标上的Chown命令在GNU版本上不会失败，RUST触发错误。 https://github.com/uutils/coreutils/pull/1694

LLVM Toolchain依赖于CMake。就像Firefox一样，我没有面临任何问题。

最近，James Robson增加了一个新的测试来运行Rust / Coreutils上的GNU TestSuite。 ＃总计：611＃通行证：144＃XPIP：86＃xFail：0＃Fail：342＃Xpass：0＃错误：39与GNU版本的546测试相比。即使一堆错误只是不同的输出，它也表明前方仍然存在漫长的道路。

首先，我们将需要更多有动力的贡献者在这个项目上工作。仍有许多功能仍有待实现，要完成的优化（例如，减少内存使用情况）等。我开始为新人创建一个好的第一个错误列表：

帮助改善GNU Coreutils Testsuite的支持将是一个巨大的一步，而学习Rust！

然后，一旦它处于更好状态，我们将能够在Debian / Ubuntu到GNU / Cororutils中的可靠替代品。 对于更喜欢GPL的BSD许可的其他人来说，这可能也有趣。