瓶子appimage
Continuous
该存储库创建并分发非官方的 Bottles Appimage。
放弃
动机
施工方法
使用 Conty 构建瓶子
为什么是康蒂？
为什么 Conty 成为 AppImage？
下载
以前的替代方法
故障排除
制作人员
轻松安装和更新
官方 Bottles 包仅以 Flatpak 形式提供。
所有构建方法均基于非官方 AUR 包，位于 https://aur.archlinux.org/packages/bottles
任何抱怨都只是由于这种心理封闭！
作为一名打包者，我只能遵循我的上游或非官方开发人员给我的东西。
开发者和打包者是两个完全相反的类别：
开发人员创建程序
打包者将其捆绑并分发（如 deb、rpm、flatpak、snap、appimage...）以供能力平台使用。
开发人员当然有兴趣看到他的应用程序在任何地方都可以工作，因此如果一个包在某个平台上工作或不工作，那么打包者就有责任使其兼容。
Bottles 项目中最大的障碍是一些合作者，为了支持 Flatpak 作为唯一的包装格式，他们对每一个使用替代包装格式的请求或建议都坚决拒绝。遇到一些傲慢的人后，他们继续做与他们所说的相反的事情。
我感谢 Bottles 的开发者 @mirkobrombin，他在多次尝试后帮助我构建了 AppImage，并告诉我提示和技巧。感谢米尔科！
我曾多次尝试允许非 Flatpak 用户以替代方式使用 Bottles，但并非没有困难。
目前，唯一可靠的方法是通过 Conty。
目前，我制作的AppImage包含以下结构：
|---- AppRun |---- com.usebottles.bottles.desktop |---- com.usebottles.bottles.svg |---- conty.sh
AppRun是AppImage的核心脚本
Bottles 的 .desktop 文件
瓶子的图标
Arch Linux 容器名为“conty.sh”，它包含 Bottles、WINE 和图形驱动程序
第 1、2 和 3 点是任何 AppImage 的基本元素。
脚本“conty.sh”(4) 是此 AppImage 元素中最重要的一个。
这就是我工作流程中每个文件的用途：
create-arch-bootstrap.sh 创建一个 Arch Linux chroot，其中 Bottles 从 AUR 安装。这是要使用的第一个脚本（需要“root”）；
create-conty.sh 是此过程中使用的第二个脚本，它将“create-arch-bootstrap.sh”创建的 Arch Linux chroot 转换为名为“conty.sh”的大脚本，其中包括“conty-start.sh” ”;
conty-start.sh 是负责启动初始化过程以使 Conty 工作的脚本。它包含一个检测所需 Nvidia 驱动程序版本的功能，如果需要，脚本会下载并将它们安装在 ~/.local/share/Conty 中。它还负责使用“bubbblewrap;”将 Conty 与主机系统完全集成。
utils_dwarfs.tar.gz包含“dwarfs”，一组类似于squashfs的压缩文件系统的工具，需要尽可能地压缩“conty.sh”；
Bottles-conty-builder.sh 是我编写的一个脚本，用于在 AppRun、.desktop 文件和图标附近处理“conty.sh”，以将所有内容转换为 AppImage。它可以在 github 操作中使用，但可以在本地执行，以使用我的 Conty 分支中的“conty.sh”测试版本来构建创建 AppImage。
文件 1、2、3 和 4 来自我的 https://github.com/Kron4ek/Conty 分支
文件 1、2 和 3 是原始文件的修改版，使它们更小，并且仅包含使 Bottles 工作所需的内容。
要了解有关“Conty”的更多信息、下载更完整的版本或了解有关如何创建自己的版本的更多信息，请访问该项目的官方存储库：
Conty 是一个具有自己资源的便携式 Arch Linux 容器。
如果容器本身没有可用的话，它是唯一安装自己的 Nvidia 驱动程序副本的解决方案（见下图）。
驱动程序安装在 ~/.local/share/Conty 目录中，最多可占用 700 MB 的空间。
考虑到 Bottles 在第一次启动时下载必要的库并为 WINE 创建配置文件，在 ~/.local/share/bottles 中达到了大约 1.4 GB 的空间，我想说这个大小是可以接受的。
这有点像安装 Flatpak 运行时。但只有一个。其余文件存储在 Conty 本身中。
将 Conty 包装到 AppImage 中可以使用我的包管理器“AM”将其隔离（通过 bubblewrap 沙箱）。
此 AppImage 是新一代 AppImage（Type3 AppImage），因此您不需要在系统上安装libfuse2即可使用它。
您可以从 https://github.com/ivan-hc/Bottles-appimage/releases/tag/continuous 下载 AppImage
可用的资源很少，这促使我在自己的可能性范围内不断尝试和犯错，或多或少有效。
康蒂的使用只是一个长系列中的最新一个。
旧的构建脚本在此存储库的目录中可用：
“legacy”包含在 JuNest 之上构建 AppImage 的实验脚本，但它缺乏硬件加速，请参阅 ivan-hc/ArchImage#20
“hybrid”之所以有效，是因为我的两个项目 AppImaGen 和 ArchImage 的混合，即 Arch Linux 和 Debian 软件包的混合。它仅适用于较新的发行版，直到更新为基本的 Arch Linux 软件包（python）为止，这种方法并不好继续维护。仍然可以下载此方法的唯一可用版本，网址为 https://github.com/ivan-hc/Bottles-appimage/releases/tag/51.11-2
鉴于此存储库的“麻烦”历史，我不知道 Conty 是否是我工作流程的最终解决方案。这完全取决于上游开发人员或第三方向我提供的软件包。
首次启动时，如有必要，将通过 Conty 下载视频卡的驱动程序（参见上面的屏幕截图）。这可能需要几秒钟甚至几分钟。仅当您首次启动时从终端启动 Bottles 而不是使用启动器时，才会注意到此行为。
bottles-cli用法为此 Appimage 创建一个符号链接“ bottles-cli ”并将其添加到 $PATH 中，因此当您将程序添加到桌面时，您将能够从带有相关图标的菜单中启动它。如果您使用“AM”和“AppMan”安装“bottles”，则该功能已经可用。
@mirkobrombin 感谢我所表现出的耐心和可用性
康蒂 https://github.com/Kron4ek/Conty
“AM”/“AppMan”是一组用于安装、更新和管理 AppImage 包和其他可移植格式的脚本和模块，就像 APT 管理 DEB 包、DNF 管理 RPM 等一样......使用受 Arch 用户存储库启发的大型 Shell 脚本数据库，每个数据库专用于一个应用程序或一组应用程序。
“AM”/“AppMan”的引擎是“APP-MANAGER”脚本，根据您安装或重命名的方式，它允许您在系统范围内（对于单个系统管理员）或本地（对于每个用户）安装应用程序）。
“AM”/“AppMan”旨在成为所有 AppImage 包的默认包管理器，为它们提供一个安身之所。
您可以在portable-linux-apps.github.io/apps查阅托管应用程序的完整列表。
| 安装“AM” | 查看所有可用的应用程序 | 在 ko-fi.com 上支持我 | 在 PayPal.me 上支持我 |
|---|
