Repository navigation
Conversation
The install layout is inferred from the executable path, and anything under /usr/bin was a .deb install. A distribution's own package installs there too. On such a host `capsem update` downloaded the .deb, asked for sudo and failed in the privileged script because apt-get does not exist. Automatic updates repeated that on every poll, and because the binary step fails first the VM assets were never refreshed either. Add InstallLayout::SystemPackage for /usr/bin without apt-get. It is offered no installer, like the user-dir and development layouts, so the update goes straight on to the VM assets, and the user is told that the package manager updates the programs.
mangeshraut712
left a comment
mangeshraut712
left a comment
There was a problem hiding this comment.
Skipping the binary step and still refreshing VM assets is the right outcome for a distro-packaged install.
| fn layout_for_package_manager(layout: InstallLayout, apt_get_present: bool) -> InstallLayout { | ||
| match layout { | ||
| InstallLayout::LinuxDeb if !apt_get_present => InstallLayout::SystemPackage, | ||
| other => other, | ||
| } | ||
| } |
There was a problem hiding this comment.
"apt-get exists" answers can a .deb be installed here, but the question that matters is was this binary installed from our .deb. Those differ on Debian/Ubuntu hosts: if Capsem comes from the distro's own archive or a PPA, or someone copied the binary into /usr/bin by hand, apt-get is present, the layout stays LinuxDeb, and the updater will swap in the release .deb over a package another source owns. The next apt upgrade would then fight it.
Asking dpkg about the actual file would cover both cases with one check: dpkg-query -S <exe path> (or reading /var/lib/dpkg/info/<pkg>.list) says whether the file belongs to the package name the release .deb uses. If it doesn't, or dpkg isn't there, return SystemPackage. The pure layout_for_package_manager(layout, owned_by_release_deb: bool) shape would stay just as testable.
The install layout is inferred from the executable path, and anything under
/usr/binis treated as a.debinstall. A distribution's own package installs there too. On such a host:capsem updatedownloaded the.deb, asked for a sudo password, and only then failed inside the privileged script because/usr/bin/apt-getdoes not exist.This adds
InstallLayout::SystemPackagefor/usr/binwithout apt-get. It gets the treatment the user-dir and development layouts already have: no installer is selected, so the update goes straight on to the VM assets. The user is told:.debinstalls are unchanged: with apt-get present the layout is stillLinuxDeb.install_bin_dir_forreturnsNonefor the new layout, socapsem uninstallleaves the package manager's files in/usr/binalone.Tests. Four new unit tests in
platform/tests.rs(layout selection with and without apt, no other layout affected, no install bin dir, the message) and one added assertion in the existing deb installer test. They fail to compile before the change;cargo test -p capsem --bin capsempasses (394) and clippy is clean.The message lives on
InstallLayoutrather than inupdate.rs, and the installer check is an assertion rather than a new test, soupdate.rsandupdate/tests.rsstay at their line ratchet inconfig/gate.toml.Not verified. I have not run this against a release channel that is ahead of the installed version, so the "newer release exists" path is covered by the unit tests only.
🤖 Generated with Claude Code