Debian packaging

[atheriel]

At the moment we basically encourage users to compile from source, although I'm aware of packages in the AUR, in Void Linux, and in NixOS.

One way to broaden the reach of this project considerably would be to make a Debian package (.deb) available, since many distributions can use them either directly or as the basis of their own packages. A Debian package could also provide a partial solution to #401, and there appears to be a popular cargo deb subcommand to make this process easier, too.

I'm also willing to attempt to get i3status-rust included in Debian itself, if that's appealing to others (although I am not a Debian user myself).

[atheriel]

For anyone interested in this, I build a .deb file for release 0.11.0 that can be downloaded via GitHub. I'd love to hear feedback.

[atheriel]

Also, for future reference, you can build .deb files by using the cargo-deb branch of this repository. Rebase the branch against master and run cargo deb in the project root.

If you don't have a Debian environment around to check if things are working, you can use Docker, e.g.

$ docker run -v `pwd`/target/debian/:/deb -it debian
root@13068fa4ee15:/# ls /deb/
ext  i3status-rust_0.11.0_amd64.deb

To poke around with the .deb file try dpkg-deb -I <deb> and dpkg-deb -c <deb>. To install it, use dpkg -i <deb> -- you will then be prompted to install the dependencies.

[ammgws]

I guess the next step could be providing a ppa? Don't know how much of a hassle it is though

[ammgws]

If someone wants to submit a RFP or ITP refer to the guide here: https://www.debian.org/devel/wnpp/

[cfsmp3]

I'm working on this. But if the branch cargo-deb is not being used - it should just be removed to avoid confusion.

Packaging this is being painful because there's plenty of dependencies that just don't exist yet in Debian. So in order to successfully package i3status-rust I need to first package all of this:

dpkg-checkbuilddeps: error: Unmet build dependencies: librust-chrono-0.4+unstable-locales-dev librust-chrono-tz-0.6+default-dev librust-chrono-tz-0.6+serde-dev librust-crossbeam-channel-0.5+default-dev librust-dbus-tree-0.9+default-dev librust-inotify-0.9-dev librust-libpulse-binding-2-dev librust-nix-0.23+default-dev librust-nl80211-0.0.2+default-dev librust-regex-1+std-dev (>= 1.5-~~) librust-shellexpand-2+default-dev (>= 2.1-~~) librust-signal-hook-0.3+default-dev librust-swayipc-2+default-dev (>= 2.7-~~)

Hopefully once this is done future updates will be easier.

[MaxVerevkin]

Packaging this is being painful because there's plenty of dependencies that just don't exist yet in Debian.

Wow, you mean in Debian you have to package every rust dependency? And they are dynamically linked? Like Haskell on Arch?

[cfsmp3]

Packaging this is being painful because there's plenty of dependencies that just don't exist yet in Debian.

Wow, you mean in Debian you have to package every rust dependency? And they are dynamically linked? Like Haskell on Arch?

There's binary packages in debian of course, but the distribution needs to have source packages and those can only depend on other source packages, etc.

So current status is:

dpkg-checkbuilddeps: error: Unmet build dependencies: librust-chrono-0.4+unstable-locales-dev librust-chrono-tz-0.6+default-dev librust-chrono-tz-0.6+serde-dev librust-crossbeam-channel-0.5+default-dev librust-dbus-tree-0.9+default-dev librust-inotify-0.9-dev librust-libpulse-binding-2-dev librust-nix-0.23+default-dev librust-nl80211-0.0.2+default-dev librust-regex-1+std-dev (>= 1.5-~~) librust-shellexpand-2+default-dev (>= 2.1-~~) librust-signal-hook-0.3+default-dev librust-swayipc-2+default-dev (>= 2.7-~~)

So first - those dependencies need to be solved (by creating the required source packages).

[cfsmp3]

On the fun topic of Debian packaging:

For regolith-linux we -for now, anyway- absolutely require Debian source packages (i.e. no cargo-deb).

Getting this upstreamed into Debian is going to take months because each dependency (recursive) needs to be uploaded individually and there's a lot of steps to get that done, merged, approved (not the same thing, and not by the same team!), plus they don't like having several versions of the same crate around unless it's really popular, so for example our usage of nl80211 which depends on a very old version of neli is a problem (suggested solution is that we refactor nl80211 so it uses the newest neli, upstream that, and finally contribute... you get the idea).

Anyway, while I'm doing all of that, there's no way this is going to stop the actual work I cared about which is getting i3status-rs into regolith, so I just prepared a package that vendors all the stuff.

Really tentative:
https://github.com/cfsmp3/i3status-rust/releases/tag/v0.20.7deb

Note that I created a Makefile which I think can be avoided by just running cargo from debian/rules, but this was just an attempt to get it to work ASAP.

Debian files are pretty much the bare minimum to get stuff to build. Probably incorrect, and definitely incomplete (specifically, the copyright one).

Anyway it's a starting point. I will get it to a point in which it can be added to regolith's PPA, and then I'm done :-)

Comments welcome. Maybe part of it (not the debian directory though) could be added to the main repo so it doesn't need to be part of the Debian package patches.

[MaxVerevkin]

suggested solution is that we refactor nl80211 so it uses the newest neli

Already did that :) Although it has a few breaking changes and the owner of the crate hasn't been around for more than a year, so I haven't opened a PR.

[cfsmp3]

suggested solution is that we refactor nl80211 so it uses the newest neli

Already did that :) Although it has a few breaking changes and the owner of the crate hasn't been around for more than a year, so I haven't opened a PR.

Nice, I was going to do it myself :-)
We should do something about it - it's going to be a problem at some point if the guy is gone. Either replace it with something else, or use your fork...

[MaxVerevkin]

By the way @cfsmp3, what's the point of https://crates.io/crates/i3status-rs? Users still can't just cargo install (cargo is unable to install arbitrary files).

[cfsmp3]

By the way @cfsmp3, what's the point of https://crates.io/crates/i3status-rs? Users still can't just cargo install (cargo is unable to install arbitrary files).

It was required for cargo-deb (it depends on a crates.io crate). Dead end.

[cfsmp3]

I'm working on a docker based Debian packager. Current version here:

https://github.com/cfsmp3/regolith-i3status-rust-deb-packager

Note that "regolith" appears in the name there as in my fork if i3status-rust to avoid name collisions (in case there's an official package different to the one regolith will use, even though there's no reason for that at this point).

As you can see that packager is quick and dirty, but it gets us to the goal.

I will clean up once 0.20.8 it's released.

[cfsmp3]

V2 : https://github.com/cfsmp3/i3status-rust-docker-from-scratch

This one is stand alone - no need to have any pre-existing file.

[cfsmp3]

Status report today on the official Debian repos.
Some of my dependencies packages have been approved and merged.

Still missing

librust-chrono-0.4+unstable-locales-dev librust-chrono-tz-0.6+default-dev librust-chrono-tz-0.6+serde-dev 
librust-inotify-0.9-dev
librust-libpulse-binding-2-dev
librust-nl80211-0.0.2+default-dev 
librust-signal-hook-0.3+default-dev 
librust-swayipc-2+default-dev (>= 2.7-~~)

Merged

librust-dbus-tree-0.9+default-dev
librust-shellexpand-2+default-dev (>= 2.1-~~) 
librust-nix-0.23+default-dev  #  I think someone else did his one or my Alzheimer's is kick in already
librust-regex-1+std-dev (>= 1.5-~~) 

Note that since there's already a valid solution to generate source (and therefore binaries) packages that are stand-alone (by vendoring all dependencies, of course) and can be added to a PPA (which we need to have for regolith, anyway) this is less urgent for me personally, but I'll complete this work anyway so we have an official Debian package.

[cfsmp3]

@MaxVerevkin On the issue of neli and nl80211 - this is a blocker for official Debian packages, they won't accept an old neli version:

https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/250#note_292962

If the original developer of nl80211 is MIA which seems to be the case (last github activity was on 2020) maybe it's time to release your fork on crates.io and package that one?

[MaxVerevkin]

maybe it's time to release your fork on crates.io and package that one?

https://crates.io/crates/neli-wifi

62a302a

[cfsmp3]

maybe it's time to release your fork on crates.io and package that one?

https://crates.io/crates/neli-wifi

62a302a

Great, merged.

https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/250

Slowly chipping the tree so we get all our dependencies (recursively) in place. Jesus.

[hwittenborn]

If you want to use (mostly) the same PKGBUILD found on the AUR, makedeb should provide a great way to do that. It uses the same file format, and still gives you a .deb that any user can install on their system.

---

P.s. makedeb is a personal project of mine.

[cfsmp3]

@hwittenborn we do have that, the problem is not creating a binary debian package, it's creating a source package (which in turn must depend on other source packages). It's taking forever because Debian approach is to have just version of each package, and that's totally the opposite of rust in which it's totally OK, and normal, for each crate to depend on specific versions of other crates without having a shit if they're the last or not.

So pretty much the only way to get this into Debian is to submit the whole dependency tree updating stuff as needed.

And then, each thing requires an approval, and actual upload (which someone who is very busy needs to do manually), etc.

So well, it's taking forever, but it is what it is.

[hwittenborn]

Understood @cfsmp3, that's my bad for the confusion.

The Debian packaging process isn't too fun for me either, thus why I made makedeb. I didn't see the stuff about binary Debs already existing, thus why I chimed in.

Thanks for the quick response regardless! :)

[cfsmp3]

Status today. Missing packages upstream:

dpkg-checkbuilddeps: error: Unmet build dependencies: librust-chrono-0.4+unstable-locales-dev librust-inotify-0.10-dev librust-libpulse-binding-2-dev librust-neli-wifi-0.3+default-dev librust-nix-0.23+default-dev librust-swayipc-3+default-dev

[kgilmer]

The constraints of Debian packaging policy and the nature of i3status-rs seem to naturally compete: i3statusrs will continue wanting to provide more system information, which will require more dependencies. One approach to resolving this would be to adopt a plugin model into i3status-rs. Blocks with problematic dependencies from a distro perspective could be held back without preventing the core project and blocks with more modest dependencies from being available via pacakge. I have not implemented this in rust myself, but from some reading it seems that ABI stable plugins can be implemented in Rust today.

In addition to a plugin model, the other piece required for i3status-rs to be packaging friendly is to allow for "conf.d" style config partials, as i3 and Sway already support. This constraint stems from the policy that only one package may provide a single file on a target system. Monolithic config files prevent package managers from integration.

I wonder if a plugin abstraction and conf.d style configuration has come up before in the project? I can certainly see cons to this...adding abstraction adds additional complexity. The plugin loading would likely incur additional startup performance overhead. For users that have no need/desire for some distro packaging support in i3status-rs, there would be no upside. The upside would be in greater availability of i3status-rs for those that desire to consume it from their OS package manager.

[MaxVerevkin]

Can we just make the "problematic" blocks optional? Users that wish to use them would build from source, just as they would have to build plugins from source.

---

Monolithic config files prevent package managers from integration.

I'm not sure which integration they need. Provide a default config? Change defaults?

[kgilmer]

Can we just make the "problematic" blocks optional?

Sure, but the goldielocks set of dependencies for Distro A is sure to vary with Distro B. This might lead to confusion about what specific features are "built in" for some specific distro. But I think the packaging story can offer a better experience; w/ a suitable plugin mechanism, plugins could be packaged just as the core project is. So, I could install and configure, say a battery block entirely by installing a package which provides the plugin shared library and a default configuration partial (or none if 100% defaults are available).

Provide a default config? Change defaults?

Yes, this gets to my idea above. If a plugin is provided by a package, it cannot be that a single file (owned by another package) is mutatable. The integration with package managers require that the i3status-rs configuration can be expressed without requiring a single file w/ shared ownership (across packages in this case). As it stands, I believe i3status-rs's config.toml is problematic. (A first step here may be to allow i3status-rs to read it's configuration via stdin if the input file name is the string literal -..)