新的Linux包管理方式与目录结构

特性：

• 模块化

• “热插拔”

• 稳健性

• 读、写、执行分离

• 易于访问控制

模块化

整个系统如同拼图版一样拼成。并且呈现一定的层次结构：

• 微核：由内核+initrd构成，其中initrd的要求是启动、恢复系统的最小集合：

  • initrd不能依赖除内核、自身以外

  • 能够恢复系统——恢复核心环境（C库、包管理系统...）

  • 含klibc、busybox、必要的模块

• 核心环境：具备一定完整功能的最小集合：

  • C库

  • 包管理系统

  • init

  • ...

• 其他环境

一个示例的目录结构：

说明：这是一个原生(Native)文件系统上的本地磁盘布局。Files文件夹存放字体、墙纸之类的资源。

PuzzleFS

PuzzleFS是假象中的实现“热插拔”功能的用户态文件系统(FUSE)。PuzzleFS还是用来实现访问控制的文件系统。

PuzzleFS管理着系统可以执行代码的文件系统命名空间视图。因此，PuzzleFS启动后，对文件系统的读写都交由PuzzleFS进行访问控制，可能地记录到数据库，最后分流到各自源上的原生文件系统实现。
PuzzleFS上的目录结构指定，类似示例目录结构。这样，它和主源的映射关系就比较简单。所不同的是，PuzzleFS是所有源的混合，其某个文件夹下的内容是多个源对应文件夹的并集。
当新的包发现时（新源挂载，或者包下载复制到对应目录——依据配置在执行域中），启动“热插拔”历程。
“热插拔”时，首先读取/验证新包的meta信息。meta信息包括以下：

1. 数字签名
2. 依赖关系（例如冲突...）
3. 访问控制规则（基于路径的正则表达式匹配，可以更复杂地制定主体。当然这意味着对建链接的额外关注）
4. 包的所属环境
5. 包的分类
6. 图标
7. ...

讨论：
熟悉Singularity的朋友，可以想象依赖关系和访问控制规则是其相应风格的（MBP...）？
另外，这个方式符合“现代”的安全实现方式：在进行动作前，基于某种描述方式来对动作的影响进行描述，之后验证该动作不违背先前描述。因此，在系统辅助不产生冲突的情形下，软件的安全规则由软件开发者提供（没有人比软件开发者更了解软件的正常行为）
“热插拔”的第二阶段，是可选，为解包阶段。即包如果是压缩，或者需要安装时刻动作（比如编译...），则进行相应动作。包解包后存放的实际地址可以指定源。
第三阶段，为新包分配相关“资源”。包的内容是只读的，并且只有指定目录下的文件可以有可执行的权限（bin、lib）。因此，比如为包分配一个影子etc目录（在System下某个目录中或者用户目录下的某个目录下），当有程序改写etc目录中的内容时，则执行一个COW（Copy On Write），结果在影子etc目录下)
第四阶段，包的注册阶段。包的某些内容写入数据库（Sytem某个目录下）。这样做是因为：

• 比如，包中lib是公开的，则其下文件等内容数据库索引。对bin下的内容也是，加快相应操作
• 包的meta中的信息，比如实现分类，方便用户分类搜索浏览
• 包的源来分类浏览
• 包是封装的，任何其他包不能访问包中的非公开文件（配置文件)，则在数据库中注册（通用接口的）配置信息，即这是类似注册表或者GConf的。

总结：

PuzzleFS实现了“热插拔”、访问控制、包封装、搜索、通用接口的配置功能。

• 访问控制机制是通过PuzzleFS是对多个原生文件系统统一封装的用户态文件系统的自然结果。

• 包的封装是指对包的访问，（在访问控制规则许可下）限制只可对bin、lib以及通用配置信息的访问。其他，比如外包不能访问非本包的etc下文件。

• 搜索。是由于PuzzleFS背后有数据库支持的结果。用于比如加快输入命令，链接库等的查找，分类视图的作用。这是对之前硬盘搜索的自然嵌入（想像微软未曾经计划的WinFS、苹果的spotlight搜索、Novell的beagle...）

• 通用接口的配置。使得PuzzleFS扮演了注册表(GConf）的角色，用于包配置信息的导出共享等。相比注册表，这里的实现方式更加稳健：所有PuzzleFS数据库中的信息只是一个缓冲，出现问题后可以方便重建的。