Basic design

[ikeycode]

Jotting down prior to a meeting..

Aim for Solus support first, with reusable core library for moss

• bincode for the state DB
• clap for CLI handling
• ion-rs for trigger compilation into shared trigger state (cascade stateless)
• ion-schema for CLI tool to validate triggers at package build time
• thiserror because we're not insane.

Use a digraph and likely rayon to get best runtimes from usysconf. Less time doing repeat work.

Experimenting initially with ion for our trigger definition due to strong typing guarantees

[EbonJaeger]

Out of curiosity, what would be different in a Solus vs Serpent implementation? Is there anything keeping it from being completely agnostic between the two, so both can benefit from it immediately?

[ikeycode]

I'd like to share as much as possible. Main difference I think is that the Solus implementation needs the wrapper binary and has no path knowledge, as pisi can't pass that stuff along in terms of "what changed" in a trivial fashion.

moss would directly link usysconf crate and notify of the changes, ie not needing the mtime approach

[EbonJaeger]

Ah, okay. Yeah, that would be really nice for moss. Basically, the binary would take the place of moss in that environment, sorta kinda.

[ikeycode]

Right, think of /usr/sbin/usysconf as a moss-adapter. Internally they'll both do the same thing and have 100% compatibility - pushing both projects forward. ^_^

[EbonJaeger]

Awesome! That makes perfect sense.

[livingsilver94]

• ion-rs for trigger compilation into shared trigger state (cascade stateless)
• ion-schema for CLI tool to validate triggers at package build time

We almost unanimously chose to use YAML + schema validation instead of Ion.