Component
cosh-ng
What problem are you trying to solve?
Follow-up to #3367 / #3366 and the discussion about separating shell functionality from login-shell configuration.
RPM currently manages /etc/shells registration in package scriptlets. The current cosh-ng raw artifact does not provide equivalent login-shell registration/configuration hooks. Users and image builders need a clear, consistent way to inspect and configure login-shell integration without treating package installation as consent to change an account's shell.
Three independent choices need explicit boundaries:
- Install and run cosh.
- Register a cosh executable as an available login shell and, separately, select it for a specified account.
- Opt into Agent session integration such as AW processing and an on-demand Herdr sidebar.
A user who starts cosh manually should be able to use future AW/Herdr integration without first changing their account's login shell. Conversely, selecting cosh as a login shell must not automatically enable AW, launch Herdr, or modify global Agent hooks.
What would a useful outcome look like?
- A documented, explicit management entrypoint reports the actual cosh executable path, registration state, and a specified account's configured login shell. Installation, registration, account selection, and Agent integration are distinguishable states.
- Registration/unregistration and setting/restoring an account's shell have separate semantics. The target account and required privileges are explicit; user-mode raw installation does not implicitly mutate system configuration.
- RPM, supported raw installation modes, and image provisioning have documented ways to invoke the same supported behavior where applicable. Paths are resolved for the actual installation rather than hardcoded to
/usr/bin/cosh.
- Repeated operations are idempotent. Unrelated
/etc/shells content, symlinks, and relevant metadata survive; failures are visible and do not corrupt the existing configuration.
- Account-shell restoration uses an explicitly selected target or validated previously recorded state, and does not overwrite subsequent administrator changes.
- Unregister/uninstall handling checks for accounts still using the shell and accounts for replacement providers. Direct package-manager removal retains its lifecycle protections; the new command must not become the only safe removal path.
- AW enablement and Herdr display remain session-level opt-ins with their own configuration and ownership. Neither depends on making cosh the default login shell.
Possible approach
Define the public command contract first. The discussion proposed cosh-shell login-shell status | enable | disable; the final public executable and subcommand names remain design decisions. Avoid overloading enable/disable to ambiguously mean both system-wide registration and per-account selection.
Separate reusable login-shell configuration behavior from packaging-specific lifecycle entrypoints. Package scriptlets, raw integration, and image provisioning can reuse it where appropriate, while retaining the ability to perform required uninstall cleanup after package files have been removed. Do not make scriptlets depend on an executable that no longer exists at their execution phase.
Validate supported RPM/raw modes with isolated fixtures or containers: status, registration and account selection, repeat execution, explicit restoration, privilege failures, interrupted updates, administrator edits/symlinks, uninstall while in use, and provider replacement. Verify that ordinary installation does not change account shells or activate AW/Herdr.
Scope and related work
Component
cosh-ng
What problem are you trying to solve?
Follow-up to #3367 / #3366 and the discussion about separating shell functionality from login-shell configuration.
RPM currently manages
/etc/shellsregistration in package scriptlets. The current cosh-ng raw artifact does not provide equivalent login-shell registration/configuration hooks. Users and image builders need a clear, consistent way to inspect and configure login-shell integration without treating package installation as consent to change an account's shell.Three independent choices need explicit boundaries:
A user who starts cosh manually should be able to use future AW/Herdr integration without first changing their account's login shell. Conversely, selecting cosh as a login shell must not automatically enable AW, launch Herdr, or modify global Agent hooks.
What would a useful outcome look like?
/usr/bin/cosh./etc/shellscontent, symlinks, and relevant metadata survive; failures are visible and do not corrupt the existing configuration.Possible approach
Define the public command contract first. The discussion proposed
cosh-shell login-shell status | enable | disable; the final public executable and subcommand names remain design decisions. Avoid overloadingenable/disableto ambiguously mean both system-wide registration and per-account selection.Separate reusable login-shell configuration behavior from packaging-specific lifecycle entrypoints. Package scriptlets, raw integration, and image provisioning can reuse it where appropriate, while retaining the ability to perform required uninstall cleanup after package files have been removed. Do not make scriptlets depend on an executable that no longer exists at their execution phase.
Validate supported RPM/raw modes with isolated fixtures or containers: status, registration and account selection, repeat execution, explicit restoration, privilege failures, interrupted updates, administrator edits/symlinks, uninstall while in use, and provider replacement. Verify that ordinary installation does not change account shells or activate AW/Herdr.
Scope and related work