FHS的替代品有哪些？

我是Linux的长期用户，已经有15年以上的时间，但是我讨厌的一件事是强制性的目录结构。我不喜欢那/usr/bin是二进制文件或库的倾销地/usr/lib，/usr/lib32，/usr/libx32，/lib，/lib32等...随机的东西在/usr/share等，这是愚蠢和混乱。但是有些人喜欢它，口味也有所不同。

我想要一个目录结构，其中每个包都被隔离。试想一下，如果媒体播放器Dragon拥有自己的结构：

/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so

要么：

/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...

你明白了。我有什么选择？是否有使用我的方案的Linux发行版？是否可以将某些发行版修改为可以正常运行（Gentoo ??）或需要LFS？这个领域有任何现有技术吗？像有关该计划是否可行的出版物一样？

不是在寻找OSX。:)但是以OS X为灵感是完全可以的。

编辑：我不知道如何PATH，LD_LIBRARY_PATH和取决于一小部分路径的其他环境变量应该计算出来。我在想，如果我安装了KDE编辑器Kate，/software/kate/bin/x86/bin/kate则可以键入二进制文件的完整路径来启动它。dlopen我不知道它应该如何用于动态库和调用，但这不是一个无法解决的工程问题。

首先，一个预先的利益冲突免责声明：我是GoboLinux的长期开发人员。

第二，对领域专业知识的预先要求：我是GoboLinux的长期开发人员。

当前使用的结构有几种。GoboLinux有一个，而GNU Stow，Homebrew等工具使用的功能非常相似（主要用于用户程序）。NixOS还使用非标准的程序层次结构和生活哲学。这也是相当普遍的LFS实验。

我将描述所有这些内容，然后从经验中评论如何在实践中实现（“可行性”）。简短的答案是，是可行的，但是您必须真正想要它。

GoboLinux

GoboLinux的结构与您所描述的非常相似。软件安装在/Programs：/Programs/ZSH/5.0.8包含所有属于ZSH 5.0.8的文件，在平时bin/ lib/ ...目录。系统工具会在指向¹ 的/System/Links层次结构下创建到这些文件的符号链接/usr。该PATH变量仅包含单个统一的可执行目录，并且LD_LIBRARY_PATH未使用。可以同时共存多个版本的软件，但是一次只能bin/zsh主动链接一个具有给定名称（）的文件。您可以通过其他人的完整路径来访问它们。

还存在一组兼容性符号链接，/bin并/usr/bin映射到统一的可执行文件目录，依此类推。这使软件在运行时更轻松。内核补丁GoboHide允许将这些兼容性符号链接从文件列表中隐藏（但仍可遍历）。

魂斗罗另一个答案，你并不需要修改内核代码：GoboHide是纯粹的外观，内核不general²依赖于用户空间的路径。GoboLinux确实有一个定制的init系统，但这也不是必需的。

口号一直是“文件系统就是程序包管理器”，但是系统中有相当普通的程序包管理工具。您可以使用做的一切cp，rm和ln，虽然。

如果您想使用GoboLinux，欢迎您。不过，我会指出，这是一个很小的开发团队，如果您以前没有人想要使用某些软件，您可能会发现它们并未打包您想要的某些软件。好消息是，为系统构建程序通常相当容易（标准“食谱”大约三行）；坏消息是，有时情况令人不愉快，我将在下面详细介绍。

刊物

有一些“出版物”。我在linux.conf.au 2010上做了一个关于整个系统的介绍，该介绍涵盖了所有常规内容，可以从视频中获得：ogv mp4（也在您的本地Linux Australia镜像上）；我也把笔记写成散文。GoboLinux网站上也有一些较旧的文档，包括著名的“ 我不是很无知 ” ，它解决了一些反对意见和问题。我认为这些天我们的工作量有所减少，我怀疑将来的发行版将被用作符号链接的基础位置。/usr

操作系统

NixOS将每个已安装的程序放在自己的目录下/nix/store。这些目录的名称类似于/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/—加密哈希表示代表该程序的整套依赖关系和配置。该目录中所有关联的文件，在本地具有或多或少的常规位置。

它还允许您一次拥有多个版本，并可以使用其中任何一个。NixOS具有与之相关的可重复配置的整体理念：从本质上讲，它从一开始就融入了配置管理系统。它依靠一些环境操作来向用户展示正确的已安装程序。

LFS

遍历Linux From Scratch并设置所需的层次结构非常简单：只需建立目录并配置所有内容以将其安装在正确的位置即可。在构建GoboLinux实验中，我已经做过几次了，它并不比普通的LFS难得多。在这种情况下，您确实需要进行兼容性符号链接。否则，这实际上会更难，但是如果您确实想要的话，小心使用活接支架可能会避免这种情况。

我感觉曾经有一个关于LFS的确切提示，但是我现在似乎找不到。

论可行性

关于FHS的事情是它是一个标准，非常普遍，它广泛地反映了其编写时的现有用法。本质上，大多数用户将永远不会使用不会遵循该布局的系统。结果是许多软件都潜在地依赖它，而没人会意识到，这往往是完全无意的。

所有那些脚本#!/bin/bash？如果您那里没有Bash，那就不好了。这就是GoboLinux具有所有这些兼容性符号链接的原因。这很实用。许多软件在构建时或运行时都无法以非标准布局运行，因此需要打补丁以进行纠正，这通常是非常侵入性的。

基本的Autoconf程序通常会随您便安装在自己高兴的地方，并且很容易实现正确的传递过程的自动化--prefix。其他构建系统并不总是那么好，要么通过有意地烘焙层次结构，要么由主要作者编写非便携式配置。CMake是后一类的主要罪犯。这意味着，如果您想生活在这个世界上，则必须准备好在他人的构建系统中进行很多巧妙的工作。在编译过程中必须动态修补生成的文件确实很麻烦。

运行时又是另一回事。许多程序都假定相对于它们的位置或绝对存在于其自己的文件或其他人的文件中。当您开始使用符号链接来呈现一致的视图时，许多程序都有处理它们的错误（有时甚至可以说是对您无益的正确行为）。例如，某个工具foobar可能希望在其baz旁边或中找到可执行文件../sbin。根据它是否读取其符号链接，它们可以是两个不同的位置，但是它们都不正确。

/usr/share目录是一个综合问题。当然，它用于共享文件，但是当您将每个程序放在其自己的前缀中时，它们实际上不再共享。这导致程序无法找到标准图标等。GoboLinux的处理方式非常难看：在构建时，它$prefix/share是的符号链接$prefix/Shared，而在构建后，链接指向全局share目录。现在，它使用编译时沙箱和文件移动来处理share（以及其他目录），但是读取链接导致的运行时错误仍然是一个问题。

多个程序套件是另一个问题。GoboLinux从未使GNOME充分发挥作用，而且我也不相信NixOS能够做到这一点，因为布局的相互依赖性是如此之大，以至于很难解决所有问题。

所以，是的，这是可行的，但是：

• 使事物正常运行需要进行大量工作。
• 某些软件可能永远无法工作。
• 人们会看着你很有趣。

所有这些可能对您来说都不是问题。

¹版本14.01使用/System/Index，可直接映射到/usr。我怀疑将来的版本可能会删除“链接/索引”层次结构，并全面使用/usr。

²它确实需要/bin/sh默认存在。

二者GoboLinux（其F.sb提到的）和GNU guix是使用每包的目录结构与符号链接一起点到一个二进制的“当前”版本分布。

如果您想要一个稳定的系统，GoboLinux似乎是更好的选择。GNU guix明确表示尚未准备生产。GoboLinux已经存在多年了。我从来没有尝试过自己。

检查GoboLinux。

如果要更改目录结构，则应更改一些内核代码，引导过程，基于rc文件的目录运行级别以及程序包管理器，然后更改目录结构。

Linux FHS基于Sun和其他UNIX公司在1980年代后期的决定。

当时的重要更改是放弃/usr/local/并引入/opt// { bin！lib！man！...}

如果您正在寻找今天将/ usr / bin用作垃圾场的原因，我相信GNOME是最负责任的项目之一。

32位和64位库发生的事情似乎是由FHS引起的。

Solaris在/lib /usr/bin和中引入了平台特定的子目录/usr/lib。您的愿望是Sun从1988年开始如何增强基本概念。

如果每个软件包都有自己的文件系统部分，那么您将需要非常大且笨拙的环境变量PATH，LD_LIBRARY_PATH以及类似的变量。

当然，您可以自己安装软件包，然后使用GNU Modules之类的工具来管理它们是否在您的环境中，这是我们在工作的科学软件中所做的，但是我们不打算这样做。系统软件。