Learnings from the Debian/Ubuntu Package

Package Maintenance
, ,
1

I’ve noticed that some of the upstream Debian patches patch out some Atuin features that should be gated behind feature-flags. We already should have some feature flags that allow for compiling out specific features:

  1. disable-atuin-ai.patch should be gated through an explicit --feature ai.
  2. disable-benches.patch should only be enabled with the appropriate flag.
  3. disable-opentelemetry.patch patches out local atuin opentelemtry and it’s only gated through a profiling-traced build.
  4. disable-vendor.patch disables the vendored version of reqwest.
  5. disable-tree-sitters.patch disables the tree sitters atuin relies on for syntax highlighting.
  6. disable-self-update.patch disables automatic updating.
  7. disable-other-platforms.patch disables Windows builds.

I am wondering whether we could make it easier for @ncts to build Atuin with some sort of build flag array cargo build --no-default-features --features ... and help avoid maintaining the large array of upstream patches. I researched this and it seems the root cause is how debcargo resolves dependencies — even if a dependency is optional = true, debcargo will check to find an appropriate dpkg for it.

There are some clear improvements on our end we could do:

  • The syntax highlighting is not gated behind a feature flag. It should be.
  • Replacing daemonize with daemonix seems like a no-brainer. Done in #4099.
  • Loosening the dependency version restrictions seems like it’s easy and correct to do.
  • Loosening the rust compiler version should be relatively safe/easy to do too.
  • Simplifying benches by adding required-features to avoid compiling it.

It looks like that’s about it with respect to what we could do on our end to make packaging just a smidge easier for Debian/Ubuntu.

Let me know if I’m missing something, @ncts!

Thanks!

2 Likes