[Feature] 支持导入 Ubuntu/Debian 上由 update-alternatives 管理的现有工具版本

[YanzMing]

[Feature] 支持导入 Ubuntu/Debian 上由 update-alternatives 管理的现有工具版本

背景

在 Ubuntu/Debian 系统上，update-alternatives 是系统原生的版本管理工具。它通过维护符号链接，允许用户在多个提供相同或相似功能的程序之间切换。

许多开发者已经在使用 update-alternatives 管理多种开发工具：

$ update-alternatives --list java
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
/usr/lib/jvm/java-11-openjdk-amd64/bin/java
/usr/lib/jvm/java-17-openjdk-amd64/bin/java

$ update-alternatives --list gcc
/usr/bin/gcc-10
/usr/bin/gcc-11
/usr/bin/gcc-12

$ update-alternatives --list python
/usr/bin/python3.8
/usr/bin/python3.9
/usr/bin/python3.11

这个工具的优势是：无需额外安装、稳定可靠、被系统服务和脚本广泛依赖。

痛点：update-alternatives 的局限性

局限	说明
仅全局生效	无法按项目目录自动切换版本，进入不同项目需要手动 --config
不自动管理环境变量	像 JAVA_HOME、GCC_ROOT 这类变量需要手动配置
无项目级配置文件	无法将版本配置提交到 Git 仓库实现团队统一
仅限 Debian/Ubuntu	非 Debian 系系统无法使用，导致环境不统一

作为开发者，我需要同时维护多个项目，依赖不同的工具版本：

• 项目 A：需要 Python 3.8（遗留系统）
• 项目 B：需要 Java 11（Spring Boot 2.x）
• 项目 C：需要 GCC 12（C++20 特性）
• 项目 D：需要 Go 1.21（新项目）

update-alternatives 无法满足项目级版本隔离的需求。

vfox 的优势

vfox 在开发者场景下明显更有优势：

特性	update-alternatives	vfox
全局切换	✅ 支持	✅ 支持
项目级切换	❌ 不支持	✅ 支持 (.tool-versions)
环境变量自动管理	❌ 需手动配置	✅ 自动管理
跨平台支持	❌ 仅 Debian/Ubuntu	✅ Linux/macOS/Windows
多语言统一管理	❌ 每类工具独立配置	✅ 所有语言统一入口

迁移障碍

虽然 vfox 功能更强，但现有用户无法直接迁移，原因如下：

1. 重复下载：vfox 要求通过自身安装所有工具版本，这意味着我需要重新下载每个版本（每个版本几十到几百 MB）

2. 磁盘占用翻倍：已通过 apt 安装的工具链（JDK、GCC、Python 等）占用大量磁盘，再用 vfox 重装一遍会导致空间浪费

3. 维护两套环境：update-alternatives 仍被系统服务或其他脚本依赖，不能简单卸载，强行迁移会破坏系统兼容性

4. 批量迁移成本高：如果一个开发者用 update-alternatives 管理了 5-10 种工具、每种 2-3 个版本，手动在 vfox 中重现这个环境是巨大的重复劳动

期望的功能

我期望 vfox 能提供一个导入命令，复用系统中已通过 update-alternatives 安装的工具版本。

基础用法

# 查看所有已被 update-alternatives 管理的工具组
$ update-alternatives --get-selections
animate                        auto     /usr/bin/animate-im6.q16
awk                            auto     /usr/bin/gawk
c++                            auto     /usr/bin/g++
editor                         auto     /usr/bin/nano
gcc                            auto     /usr/bin/gcc-11
go                             auto     /usr/bin/go-1.21
java                           manual   /usr/lib/jvm/java-17-openjdk-amd64/bin/java
python                         auto     /usr/bin/python3.11

# 导入所有已注册的版本
vfox import-from-alternatives --all

# 导入特定的工具组
vfox import-from-alternatives java gcc python

期望行为

1. 自动检测：扫描 update-alternatives --get-selections 的输出，识别所有已注册的命令组
2. 获取版本信息：通过 update-alternatives --list <name> 获取每个工具的所有备选路径，并从路径或执行 --version 推断版本号
3. 不复制文件：仅创建引用（或符号链接），不复制或移动已有的安装文件
4. 添加管理：将这些版本添加到 vfox 的管理列表中，使其可以被 vfox use、vfox list 等命令识别

预期效果

导入后，开发者可以无缝使用 vfox 的工作流：

# 查看通过 import 导入的版本
$ vfox list java
* 8  (imported from alternatives: /usr/lib/jvm/java-8-openjdk-amd64)
  11 (imported from alternatives: /usr/lib/jvm/java-11-openjdk-amd64)
  17 (imported from alternatives: /usr/lib/jvm/java-17-openjdk-amd64)

# 在项目目录下直接切换，无需重装 JDK
$ cd project-legacy && vfox use java@8
$ cd project-modern && vfox use java@17

加分功能

如果设计上可以更完善，建议考虑：

功能	说明
优先级保留	保留 update-alternatives 的优先级设置（--install 时的数字），作为 vfox 的默认全局版本参考
双向同步（可选）	当通过 vfox 切换全局版本时，可选同步到 update-alternatives --set
环境变量映射	允许用户自定义环境变量映射规则（如 java → JAVA_HOME，gcc → GCC_ROOT）
.tool-versions 导出	将当前 update-alternatives 配置导出为 .tool-versions 文件，便于团队共享

必要性总结

视角	现状	期望
系统管理员	update-alternatives 管理全局配置，稳定可靠	保持不变，系统级配置无需迁移
开发者	无法按项目切换，效率低，环境变量需手动维护	使用 vfox 实现项目级自动切换
两者并存	需要重复下载安装，磁盘和时间浪费	vfox 应复用已有的工具安装
批量迁移	逐个工具手动配置成本高	一条命令完成所有工具的导入

核心价值：让 Linux 用户在不丢弃已有投资（已安装的工具链和系统级 alternatives 配置）的前提下，顺畅地迁移到 vfox 的现代化开发工作流。

技术可行性参考

已有类似实现可供参考：

• jenv：jenv add <jdk_path> 支持添加本地已有的 JDK
• SDKMAN!：sdk install java <version> <local-zip-path> 支持从本地 zip 安装
• asdf-vm：asdf reshim 机制，以及插件系统的灵活性
• debian-alternatives 内部数据：update-alternatives 的配置存储在 /var/lib/dpkg/alternatives/，可以直接解析

vfox 可以借鉴这些项目的经验，实现一个低成本、高兼容性的导入功能。

相关命令参考

# 列出所有受管理的工具组
update-alternatives --get-selections

# 查看某个工具组的所有候选版本
update-alternatives --list <name>

# 查看某个工具组的详细信息（包括路径和优先级）
update-alternatives --display <name>

期望

这个功能将让 vfox 成为从系统级版本管理（Debian/Ubuntu 原生方案）到现代化项目级版本管理的最佳桥梁，显著降低现有用户的迁移成本。

感谢 vfox 团队的关注与考虑！