一直有个设想，能否把传统包管理器分来，另传统包管理器（apt、yum）只负责系统层面的安装和更新，应用的安装和更新交给另外的包管理器做，针对这个设想，我总结了下面这些理由：

该包管理器为了解决传统现有的包管理器的以下问题：

• 通常情况下，在传统包管理器（apt、yum、pacman）中，系统和应用无法分开管理，这可能导致应用安装出现故障时会影响到系统的正常安装和更新，这是很多普通用户无法面对的。
• 在传统包管理器中，我们只能以root权限安装应用，这导致任何软件包都有机会获得root权限，通常来说这是不安全的（一定程度上），我们需要完全信任软件包的维护者。
• 在传统包管理器中，我们不能以普通用户身份为自己单独安装一款应用，因为通常我们需要root权限，而且只要安装就是为所有用户安装。
• 在传统包管理器中，应用的大部分文件都不是放在home目录下，而是根目录的某个其他目录中，这可能导致根分区资源紧张。

现有的其他方案存在的问题：

• AppImage方案中，重复的依赖存储导致应用包将占用过多磁盘空间，例如应用A和应用B都依赖python3（举例），那么python3这个依赖将被他们两个自带，这时同一份依赖就存储了两份，毫无疑问这是空间上的浪费，虽然硬盘资源目前并不紧缺，但是该问题仍然需要解决。
• AppImage方案中，没有良好的中心化的管理机制，倘若你需要更新某个应用，你可能需要去官网下载最新的包，然后替换，如果之前配置了desktop文件，又要去做对应的修改，这很明显不方便。
• flatpak方案中，可以说是我心目中最接近完美的方案，但是他也有相应的缺点。首先是容器机制带来的问题，例如IDE程序可能需要读取系统中的第三方库，例如需要对程序的某些部分进行修改，这些问题并不容易解决。
• flatpak方案中，其这种机制也带来了一些性能问题。
• flatpak的打包也比较困难，门槛略高
• ...

我们都能很好解决吗？

不能。

其实我们的目标并非完全解决这些问题，就比如flatpak的方案，我们不能既要容器机制带来的安全性，又摒弃它所带来的弊端，我们只能寻求一个平衡的方案。我们希望提供当前状况下的最优解，而非真正意义上的最优解。

定位

首先确定一下这款新的包管理器的定位，目前来说，我们要解决的问题只是关于普通应用程序的问题，因此该包管理器仅用于管理普通应用，类似AppStore，他并不会涉及到系统包管理器（例如apt、yum这些）。

计划

作为一个现代的包管理器，我认为他应当至少具有一下特性：

• 多依赖并存：系统中允许存在多个版本的同一个依赖，程序按照需要去调用（例如第三方库，或者runtime等）
• 多用户支持：普通用户安装应用不应当需要系统的root权限，其有权只为自己安装，root用户可为所有用户安装。
• 打包低门槛：减轻打包者的学习成本，用很简单方式去便可以构建一个软件包。
• 代码易维护：作为开源项目，代码的可读性非常重要，现有的很多包管理器由于长时间的发展，代码过于复杂，外部参与者很难参与贡献。
• 图形界面支持：图形界面暂时并不在开发计划中，但是要具有简单的接口，让任何人经过简单的学习便可开发图形界面管理程序。
• 中心化管理：具有中心化的管理平台，开发者或者打包者可以在平台中投递和更新应用。
• 应用认领：考虑到打包者与开发者并非同一人，且打包者可能没有精力对单个包长期维护，因此需要具有认领机制，可将维护不活跃的软件包重新分发维护权。
• 自动化更新机制...

目前我已经开始尝试开发了一部分，简单描述一下已经实现部分的细节：

已经落实部分

打包

最基础的就是软件的打包，这部分使用tar进行打包，使用gzip进行压缩，并且支持软链接的打包和压缩，并且可以在不解压的情况下计算解压后所占空间。

包的结构大致如下：

• 包根目录
  • files：文件夹，用于存放应用程序的主要文件
    • bin：文件夹：用于存放应用程序的可执行文件（必须，若软件本身并不是按照这个规则，那也可以是相对当前目录的软链接）
  • data：数据文件夹，内的所有文件将软链接到 工作目录/data下，也就是说，这个是可以用来安装主题，字体等内容的。
    • applications
    • icons
    • ...
  • runtime：文件夹，用于存储软件需要的依赖
    • lib：文件夹，用于存放动态链接库
    • exe：用于存放可执行文件，例如java程序可能需要jvm。
  • info：包的描述文件，类似control文件，可写入包名、版本号、作者、依赖等信息。
  • icon.png/icon.svg：图标文件，用于供图形界面程序读取包的图标。

解包

打包的反向操作。

安装

安装机制需要特殊说明，这里我需要定义两个目录：

/usr/share/finc
~/.local/share/finc

这两个目录的作用相同，区别就是一个针对全部用户，一个针对当前用户（管理器将根据当前运行的用户身份确定使用哪个）。这两个目录将称为工作目录。

工作目录的子目录data将在用户登录时加入XDG_DATA_DIRS环境变量中，也就是说：

/usr/share/finc/data和~/.local/share/finc/data

这两个目录将等同于我们通常使用的 /usr/share目录。

另外还有一个子目录exe，这个子目录将被加入到PATH环境变量中，也就是说：

/usr/share/finc/exe和~/.local/share/finc/exe

这两个目录将等同于我们通常使用的/usr/bin目录。

这么做的好处就是将包管理器本身所管理的内容于系统中现有内容隔离，提高可靠性，降低故障率。

另外工作目录还有一个子目录apps，这个目录将用于存放软件的主要文件。

安装过程

安装过程就是按照现有的规范将软件包中相应的文件该解压的解压，该链接的链接。

1. 首先将软件包解压到 工作目录/apps/包名对应文件夹下。
2. 将包中data目录下的内容链接到 工作目录/data目录下。
3. 为包中files/bin目录下的内容编写脚本，并部署到 工作目录/exe中，内容大致如下（以motrix举例）：

#!/bin/bash
export XDG_DATA_DIRS=/home/maicss/.local/share/finc/apps/app.motrix.dl/runtime/lib:$XDG_DATA_DIRS
export PATH=/home/maicss/.local/share/finc/apps/app.motrix.dl/runtime/exec:$PATH
/home/maicss/.local/share/finc/apps/app.motrix.dl/files/bin/motrix $*

4. 将生成的链接和脚本记录到一个文件中，当卸载时根据这个文件删除这些内容。
5. 将应用需要的依赖（库和可执行程序）链接到 工作目录/apps/包名/runtime中的对应目录下。（暂时未做，因为依赖的部分逻辑暂时还没实现）

至此，便基本上实现了大致的流程。

假设问答

• 怎么划分哪些是应用程序哪些是系统程序？

  • 应用程序的存在与否不影响系统环境的正常运行。

• 像虚拟机程序这种，在安装过程中必须用到root权限的怎么办？

  • 计划将安装后的部署工作从安装过程的末尾移动到程序第一次运行，但是这部分怎么实现比较好还没想好。

​

• 只支持软件吗？

  • 不是，从上述原理中可以看出，也可以安装诸如字体、主题、图标等内容。

最后

上边是对于这个东西的初步想法和实现的尝试，肯定有诸多不完善，希望大家能尽情的提出建议，由于现在只是初步，所以大家的建议将影响这个东西怎么做，做成什么样，甚至是要不要继续做。

欢迎一起讨论！！！！！！！！！！！！