Commit Graph
2 Commits
Author SHA1 Message Date
gitops 5f176995dc Install as the compositor, at upstream's paths
HyprCosmic is a fork of COSMIC, not an add-on to it, so cosmic-comp goes
where a cosmic-comp goes: $(bindir)/cosmic-comp.

This reverses the private $(libexecdir)/hyprcosmic layout. That bought a
fallback -- both compositors on disk, both sessions bootable -- and cost
coherence: a session that had to name absolute paths to find its own
binary, and no answer to "which cosmic-comp is running". The fallback
survives in a better form, because cosmic-session installs cosmic.desktop
as well as hyprcosmic.desktop and both are now served by this binary.

The consequence is stated rather than hidden: a package built from this
conflicts with the distribution's cosmic-comp over /usr/bin/cosmic-comp.
That is the honest relationship between two builds of the same program.

libexecdir is dropped from the Makefile, having been added by this fork
and used by nothing else. CI asserts the binary and both .ron defaults
land at upstream's paths, and that nothing returns to the libexec
directory -- a stray copy there is a second compositor that nothing runs
and no uninstall removes.
2026-08-10 18:21:34 +07:00
gitops 139a1de4e8 ci: build on Fedora, Debian and Arch, and assert the install stays beside COSMIC
Additive to upstream ci.yml, which is left exactly as it is. That workflow asks
whether the code is formatted, lints clean and still compiles under each feature
flag, on one Ubuntu runner. None of that stopped being worth asking when the
repository was forked, and replacing it would put a conflict in the path of
every rebase against pop-os/cosmic-comp for no gain.

What it does not ask is whether a distribution has a package called libseat-dev.
That question cannot be put to a single Ubuntu runner, so this builds in three
containers with three package managers and three sets of names -- a job failing
here means a real user of that distribution could not have built it either.

Rust comes from rustup because Debian bookworm ships rustc 1.63 and this crate
needs 1.93 and edition 2024; the packaged toolchain simply cannot build it on
one of the three targets. --default-toolchain none lets rust-toolchain.toml pick
the version, so CI cannot drift onto a compiler the project does not use.

The last step is the point of the whole thing. `make install` is staged into a
DESTDIR and then asserted over: the binary must be at libexec/hyprcosmic, and
/usr/bin/cosmic-comp must NOT exist. That is the rule that keeps installing this
fork from being a one-way door -- if it will not start, the stock session is
still on the greeter's menu to log in and fix it from. Until now that rule lived
only in a Makefile comment.
2026-08-10 16:54:20 +07:00