LinuxWave 2.6.4

Release Note 更新日志

本次把 wave selfupdate 也补上了组共享：存量共享安装升级一次就到位，不必重装。

改了什么

1. selfupdate.sh 现在也配好共享写

安装器从 2.6.3 起会给共享安装自动配组共享写；但已经装好的那棵树不会凭空获得它。这一版让 selfupdate.sh 做同一套事：

• 把安装树的属主交回去 —— 下载是拿 root 跑的（NEED_SUDO=true 时 run_cmd 就是 sudo），新文件会落成 root 属主，以前一直没交回，共享安装树会慢慢变成 root 的；
• 给共享安装树补上组共享写：groupadd -f / usermod -aG / chmod -R g+w / 目录 setgid。

升级路径于是变成一句话：

wave selfupdate

属组是 root 的系统级安装（/opt、/usr/local）不碰这套，也不会劝人去加入 root 组 —— 与安装器同一个判断。

2. 装完之后要不要重新登录？分三种情形

情形	要不要重登
这次 selfupdate 才把你加进组	要 —— 重登，或在当前 shell 跑 newgrp linuxwave
你已在组里，但当前 shell 是入组之前开的	要 —— 同上
你已经入组、并且入组之后重登过	不要 —— 权限位与组身份都已生效

chgrp / chmod g+w / setgid 是立即生效的，只有「你个人的组身份」要等新的登录会话。所以这句提示不是每次都打：只在真需要的时候出现，已经有了就明说不用重登。

3. 安装器的提示挪到更显眼的位置

共享安装的「装完要重登一次」以前藏在收尾大段文字里，现在提到选完安装目录之后的前置说明里，用黄色单独成块。安装器与 selfupdate 的措辞也统一了。

一并带上 2.6.3 的内容

如果你是从 2.6.2 或更早升上来，2.6.4 同时包含 2.6.3 的改动：共享安装本身改成 Linuxbrew 式组共享（建 linuxwave 组、把调用者加进去、整棵树交给该组并打开组写位、目录加 setgid），于是装包不再需要 sudo，也不再需要写全路径：

wave install <package>

代价照实说：组内成员可以改动整棵树，包括 lib/ 里的 wave 本体。不需要多人装包的话，别配这套组共享写即可。

升级路径

当前版本	目标	行为
2.5.0 ~ 2.6.3	2.6.4	执行自更新，并补上组共享 ✅
2.6.4	2.6.4	已是最新，短路退出

本次不涉及目录结构变更，updatedata/2.6.4/dir_structure_change 显式声明为 N，自更新会跳过迁移步骤。

为什么必须抬版本号：selfupdate 在「当前版本不低于线上版本」时会直接短路退出。不抬版本的话，已经升到 2.6.3 的用户跑 wave selfupdate 只会被回一句「已是最新」，永远走不到新的 selfupdate.sh。

另外，wave selfupdate 仍然需要 sudo，与写权限无关：它要重写 root 属主的 /etc/linuxwave_config/VERSION.json。

验证方式

• 回归套件：隔离命名空间里 133 条断言全绿（133 PASS / 0 FAIL / 0 SKIP）。本次改的是提示措辞与 selfupdate，套件里与组共享相关的断言（调用者入组、组写位、setgid、需重登提示、重复安装不再谎称刚入组、usermod 失败仍安装成功、组名反查、root:root 的树不劝人加入 root 组）逐条通过。
• bash -n：install.sh、selfupdate.sh、sandbox_test.sh 全部通过。
• 权限模型与端到端安装（2.6.3 时做的，本次未改这部分逻辑）：真实非 root 用户免 sudo 写满五个数据目录；真实跑 wave install jq 成功，输出里 sudo 出现 0 次。

其他改动

• 版本号 2.6.3 → 2.6.4，构建号 281D0117

---

Release Notes

This release extends the group-shared install to wave selfupdate: an existing shared install now gets it from one update, with no reinstall.

What changed

1. selfupdate.sh now sets up shared write too

Since 2.6.3 the installer configures group-shared write for a shared install; but an already installed tree does not gain it by itself. This release makes selfupdate.sh do the same work:

• it hands the tree's ownership back - downloads run as root (run_cmd is sudo when NEED_SUDO=true), so new files land root-owned, and they were never handed back, which slowly turned a shared tree into root's;
• it gives a shared tree its group write access: groupadd -f / usermod -aG / chmod -R g+w / setgid on directories.

The upgrade path is therefore one command:

wave selfupdate

System-level installs whose group is root (/opt, /usr/local) are left alone, and nobody is told to join the root group - the same test the installer uses.

2. Do you need to log in again afterwards? Three cases

Situation	Re-login needed?
This update is what added you to the group	Yes - log out and back in, or run newgrp linuxwave
You are in the group, but this shell was started before that	Yes - same as above
You are in the group and have logged in since	No - both the permission bits and your group identity are already in place

chgrp / chmod g+w / setgid take effect immediately; only your group identity waits for a new login session. That is why the notice is not printed every time - it appears only when it is actually needed, and says so explicitly when nothing is required.

3. The installer's notice moved somewhere more visible

"Log out and back in after this install" used to be buried in the closing notes; it now sits in the pre-flight block right after you pick the install directory, highlighted on its own. The installer and selfupdate now use the same wording.

This also carries the 2.6.3 changes

If you are coming from 2.6.2 or older, 2.6.4 includes what 2.6.3 did: a shared install is now a Linuxbrew-style group install (it creates the linuxwave group, adds the caller to it, hands the tree to that group, opens the group write bits and sets setgid on directories). Installing a package then needs neither sudo nor a full path:

wave install <package>

The cost, stated plainly: members of the group can modify the whole tree, lib/wave itself included. If you do not need several users installing packages, simply do not set the group write bit up.

Upgrade path

From	To	Behaviour
2.5.0 - 2.6.3	2.6.4	self-update runs and sets up shared write ✅
2.6.4	2.6.4	already up to date, exits early

No directory structure change is involved - updatedata/2.6.4/dir_structure_change states N explicitly - so the self-update skips the migration steps.

Why the version had to be bumped: selfupdate exits early when the installed version is not older than the published one. Without a bump, a user already on 2.6.3 running wave selfupdate would just be told "already up to date" and would never reach the new selfupdate.sh.

Also, wave selfupdate still needs sudo, independently of write permissions: it rewrites /etc/linuxwave_config/VERSION.json, which is root-owned.

How this was verified

• Regression suite: all 133 assertions pass in the isolated namespace (133 PASS / 0 FAIL / 0 SKIP). This change is about prompt wording and selfupdate; every group-shared assertion (the caller joins the group, the group write bit, setgid, the re-login notice, a second install no longer claiming a fresh group change, a failing usermod still leaving a successful install, the gid-to-name lookup, a root:root tree not being told to join the root group) passes one by one.
• bash -n: install.sh, selfupdate.sh and sandbox_test.sh all parse.
• Permission model and end-to-end install (done for 2.6.3; that logic is unchanged here): a real non-root user wrote to all five data directories with no sudo; a real wave install jq succeeded with sudo appearing 0 times in its output.

Other Changes

• Version 2.6.3 → 2.6.4, build number 281D0117

---

安装

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"

Install

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/LinuxWaveOrg/LinuxWave/HEAD/lib/install.sh)"