Packaging ringboard

[GaetanLepage]

Hi !

I would like to package ringboard on nixpkgs.
How would you actually see this software packaged on a distro ?

I ask this question because it is inherently constituted of distinct entities (server, tui client, x11 client, egui...)
Would you have it as a single meta-package shipping all binaries ?
Would each component have its own package that user would install independently ?

Thanks in advance for your help :)

[SUPERCILEX]

This is awesome, thanks for looking into packaging!

I'm not sure what the best approach is. I think it could make sense to package everything together in an x11 variant (and in the future wayland). But I can also see people not wanting bloat and preferring individual binaries. If we go that approach, then I think it's important to make sure installing the GUI for example also installs the server and a watcher so people aren't confused. Or maybe we could get the best of both worlds by packaging each binary individually with no dependencies and then offering one package which with nothing in it but dependencies on all the other packages so it acts as an everything package. Thoughts?

[GaetanLepage]

Ok, I think I will start by packaging them all individually.
I would still be able to play with "meta-packages" or dependencies later.

There is a blocker for now though, your code seems to rely on a nightly version of Rust. We are only able to compile code with the current stable rustc.
Do you plan to allow this in the future ?

[SUPERCILEX]

Ahhhh, I was wondering when the question of nightly would come up. It would be possible to create a patch that makes things work on stable, but it'll be pretty hard. Is it possible to be packaged with some reasonably recent version of nightly? And if things fail to build then you just come yell at me and I'll update to the latest version.

[msirringhaus]

I'm also trying to package it for openSUSE at the moment, and am in the same boat: No nightly available in our build-systems.
There is the highly discouraged hack of using export RUSTC_BOOTSTRAP=1, which let's one use nightly-features with stable compilers. With this, I can get it to compile, but it will make a lot of people very angry, once they find out.
Having the project rely only on stable features seems to me to be the only non-hacky solution.

[SUPERCILEX]

Is there some discussion about why folks would be mad? I think we'd accept that the package will probably break whenever rustc is updated which seems fine as long as the policy is "get rid of the package until they figure out their broken build."

In terms of nightly features, debug_closure_helpers would probably be the most painful to remove, though they'll all be a pain to deal with.

[lolbinarycat]

Is there some discussion about why folks would be mad?

RUST_BOOTSTRAP is an escape hatch that exists so that rustc and the standard library can be built with a stable compiler. it is not part of any official api, and it is not intended to be used by anyone except the compiler. it's existence is already a dirty hack that breaks the rust stability model, using it outside of rustc would be even worse.