Skip to content

Gate alternatives registration and centralize tarball target metadata#1859

Closed
oferchen wants to merge 1 commit into
masterfrom
allow-side-by-side-installation-of-oc-rsync-and-rsync
Closed

Gate alternatives registration and centralize tarball target metadata#1859
oferchen wants to merge 1 commit into
masterfrom
allow-side-by-side-installation-of-oc-rsync-and-rsync

Conversation

@oferchen
Copy link
Copy Markdown
Owner

@oferchen oferchen commented Nov 1, 2025

Summary

  • gate the Debian postinst and RPM scripts behind optional update-alternatives registration so upstream rsync can stay installed alongside oc-rsync by default
  • surface the amd64 tarball target in workspace metadata and propagate it through xtask branding/package tooling and tests
  • extend branding validations, renderers, and docs checks to cover the new tarball target field

Testing

  • cargo test -p xtask

https://chatgpt.com/codex/tasks/task_e_69057bcc17ec8323ba7ba16756c02528

@oferchen oferchen closed this Nov 1, 2025
@oferchen oferchen deleted the allow-side-by-side-installation-of-oc-rsync-and-rsync branch November 1, 2025 03:31
oferchen added a commit that referenced this pull request Apr 28, 2026
…ine (#3418)

Adds two doc-only notes covering recurring questions:

- crates/rsync_io/src/ssh/mod.rs: explains why SSH transfers cannot use
  the fast_io socket reader/writer paths. The data channel is the
  inherited stdio pipe pair from the spawned ssh child, not an AF_INET
  socket, so the io_uring socket fast path is unreachable. Mirrors
  upstream main.c:504 do_cmd(). Cross-references tasks #1859
  (pipe-FD io_uring) and #1860 (splice-based zero-copy) and notes that
  daemon TCP and local-disk transfers still benefit from fast_io.

- crates/transfer/src/generator/mod.rs: documents the sender-side
  INC_RECURSE state machine (Idle -> ScanDir -> SendChunk -> WaitAck
  -> NextDir -> Done) with upstream citations to flist.c:2192
  send_file_list(), sender.c:199 send_files(), generator.c:2226
  generate_files(), receiver.c:522 recv_files(), and compat.c:161
  set_allow_inc_recurse(). Documents that the sender side is
  implemented but disabled in build_capability_string until interop
  is validated (task #1862); the 'i' capability is not advertised
  when oc-rsync is sender.

Closes #1858, #1865.
oferchen added a commit that referenced this pull request May 1, 2026
…ine (#3418)

Adds two doc-only notes covering recurring questions:

- crates/rsync_io/src/ssh/mod.rs: explains why SSH transfers cannot use
  the fast_io socket reader/writer paths. The data channel is the
  inherited stdio pipe pair from the spawned ssh child, not an AF_INET
  socket, so the io_uring socket fast path is unreachable. Mirrors
  upstream main.c:504 do_cmd(). Cross-references tasks #1859
  (pipe-FD io_uring) and #1860 (splice-based zero-copy) and notes that
  daemon TCP and local-disk transfers still benefit from fast_io.

- crates/transfer/src/generator/mod.rs: documents the sender-side
  INC_RECURSE state machine (Idle -> ScanDir -> SendChunk -> WaitAck
  -> NextDir -> Done) with upstream citations to flist.c:2192
  send_file_list(), sender.c:199 send_files(), generator.c:2226
  generate_files(), receiver.c:522 recv_files(), and compat.c:161
  set_allow_inc_recurse(). Documents that the sender side is
  implemented but disabled in build_capability_string until interop
  is validated (task #1862); the 'i' capability is not advertised
  when oc-rsync is sender.

Closes #1858, #1865.
oferchen added a commit that referenced this pull request May 1, 2026
Document the scope of #1593 (async at the transport-level) versus the
parallel #1411 (async runtime adoption). Defer the Linux pipe-FD path
to #1859, recommend status quo on macOS / BSD / Windows / older Linux,
and articulate why the rsync wire-protocol pipeline single-threading
caps the win regardless of mechanism.
oferchen added a commit that referenced this pull request May 5, 2026
…ine (#3418)

Adds two doc-only notes covering recurring questions:

- crates/rsync_io/src/ssh/mod.rs: explains why SSH transfers cannot use
  the fast_io socket reader/writer paths. The data channel is the
  inherited stdio pipe pair from the spawned ssh child, not an AF_INET
  socket, so the io_uring socket fast path is unreachable. Mirrors
  upstream main.c:504 do_cmd(). Cross-references tasks #1859
  (pipe-FD io_uring) and #1860 (splice-based zero-copy) and notes that
  daemon TCP and local-disk transfers still benefit from fast_io.

- crates/transfer/src/generator/mod.rs: documents the sender-side
  INC_RECURSE state machine (Idle -> ScanDir -> SendChunk -> WaitAck
  -> NextDir -> Done) with upstream citations to flist.c:2192
  send_file_list(), sender.c:199 send_files(), generator.c:2226
  generate_files(), receiver.c:522 recv_files(), and compat.c:161
  set_allow_inc_recurse(). Documents that the sender side is
  implemented but disabled in build_capability_string until interop
  is validated (task #1862); the 'i' capability is not advertised
  when oc-rsync is sender.

Closes #1858, #1865.
oferchen added a commit that referenced this pull request May 5, 2026
Document the scope of #1593 (async at the transport-level) versus the
parallel #1411 (async runtime adoption). Defer the Linux pipe-FD path
to #1859, recommend status quo on macOS / BSD / Windows / older Linux,
and articulate why the rsync wire-protocol pipeline single-threading
caps the win regardless of mechanism.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant