Drop breadsearch from the default BOS install #12
No reviewers
Labels
No labels
P0
P1
P2
P3
audio
bakery
boot
breadbug
bug
build
ci
dependencies
design
disk
docs
encryption
final
firewall
graphics
hardware
idle
installer
keybinds
nvidia
packages
phase-1
polish
recovery
reliability
reproducibility
secure-boot
security
shell
signing
snapshots
supply-chain
swap
tech-debt
theming
ux
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Breadway/bos!12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/search-4-drop-breadsearch-default"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Semantic file search (
breadsearch+ itsbreadmillindexer) was baked into every BOS image andbreadmill.servicewas--global enable'd on first login. It is memory-heavy and not something every user wants running. This removes it from the default install. It stays one command away:bakery install breadsearchpulls both binaries, thebreadmill.serviceunit, and the config example.Verified against the live stable bakery index (
https://dl.breadway.dev/index.json):breadsearch0.3.3 is a standalone package that bundlesbreadmill-x86_64+breadsearch-x86_64, shipsbreadmill.service(enable: true), and has apost_installthat starts breadmill. Sobakery install breadsearchfully restores the previous behaviour.Changes
iso/bread-lockfile.toml: removebreadsearchandbreadmillfromrequired_bins; remove thebreadsearch = "0.3.2"version pin; note the opt-in path in the header comment.iso/airootfs/usr/lib/systemd/user-preset/90-bos-bakery.preset: dropenable breadmill.service(the bake regenerates this list from the units actually copied, so this just keeps the committed default honest).autostart.json,hyprland.lua,scripts/system/autostart.lua): drop thebreadsearch listencommand-bus entries. They were alreadycommand -v breadsearch >/dev/nullguarded, so on a system without breadsearch they were already no-ops.iso/airootfs/etc/skel/.local/share/applications/breadsearch.desktop: removed.iso/packages.x86_64,iso/airootfs/usr/local/bin/bos-update,iso/airootfs/etc/skel/.config/bread/modules/breadhelp-tour.lua, andiso/airootfs/etc/calamares/post-install.sh: drop the breadsearch/breadmill mentions.README.mdandpackaging/arch/README.md: document that breadsearch is not shipped by default and how to add it (bakery install breadsearch).Scope notes
bos-updatedoes not touch breadsearch on existing systems, so anyone who already has it keeps it. A forced cleanup of existing installs would be a separatebos-updatechange, deliberately not done here.build-local.sh:254untouched: it is a historical comment listing example bakery services (breadbox-sync, breadmill, breadclipd, ...) and the statement stays true (breadmill is still a bakery-package service, just not baked). That file also has unrelated in-progress local work, so I avoided touching it.Verification
python3 -c json.loadon the editedautostart.json: validluac -pon all three edited Lua files: cleanbash -nonbos-updateandpost-install.sh: cleanscripts/ci-stage-bakery.pyreadsrequired_bins/[versions]generically with no hardcoded package names, so the shorter lists are finebreadboard: SEARCH-4. Tracking issue: Breadway/breadsearch#4.
Reviewed, looks ready to merge. Leaving the merge to you since bos is on the release train.
Acceptance criteria (from the issue body and the breadsearch SEARCH-4 direction it implements): drop breadsearch/breadmill from the default install (lockfile required_bins and version pin, the breadmill.service preset, the three hypr autostart entries, the desktop launcher) while keeping it available via
bakery install breadsearch, update the assorted comments, and document the opt-in path in README.md and packaging/arch/README.md. Full diff review confirms all of that, nothing more and nothing less: 12 files, all doc/config/comment changes, no code. Scope notes in the PR body (new-installs-only, bos-update untouched, build-local.sh left alone due to unrelated in-progress work there) are accurate and appropriately conservative.One gap: I could not get a commit status for this PR (get_commit_status returned empty for both the branch and the head sha), so I cannot confirm CI actually ran here. Worth checking before merge that a check did run and passed, since bos's CI setup may differ from the other repos.
This also satisfies SEARCH-4 (breadsearch repo), since all the actual work lives in this PR per that issue's own tracking note. Commented there separately.