search

lbonn / rofi

Rofi: A window switcher, run dialog and dmenu replacement - fork with wayland support
Other
943 stars 37 forks source link

[REQUEST] Releases with tarballs #25

Closed lbonn closed 2 years ago

lbonn commented 3 years ago

Until now, this fork is just a git branch, synced with upstream at irregular intervals (mostly official releases)

There may be the need for more robust packaings, as requested here: https://github.com/lbonn/rofi/issues/24.

Please explain here your use case(s) to motivate this work.

ram02z commented 3 years ago

I am trying to package rofi-wayland for void linux, which doesn't accept programs that don't have public releases. Also, the rofi template from the void linux repo uses autotools, what is currently missing to allow building rofi with wayland support using autotools?

lbonn commented 3 years ago

To be honest, the thing with autotools is that I've always been too lazy to learn it. It's old and crufty, few new projects use it. It's also quite uncommon for a project like rofi to maintain two build systems in parallel.

As for the release, it definitely makes sense. I think upstream rofi uses autotools to make the tarballs, so that could be the reason to finally add support here. Otherwise, it should not be a problem to use meson for the void linux package either.

Can't promise I'll do it very soon, but I'll leave it on my list. Anybody is free to help as well!

ram02z commented 3 years ago

As for the release, it definitely makes sense. I think upstream rofi uses autotools to make the tarballs, so that could be the reason to finally add support here. Otherwise, it should not be a problem to use meson for the void linux package either.

~I think I saw build artifacts that created tarballs using meson.~ I have more experience with meson anyway, so unless the void maintainers are against it, I am happy with the current build process.

jirutka commented 2 years ago

I’m Alpine Linux developer and maintainer of the rofi-wayland package that provides Wayland-only variant of rofi based on this fork (there’s also package rofi that provides X11-only variant of rofi based on the original rofi upstream).

If there’s a choice between autohellstools or CMake and Meson, we definitely prefer Meson. Thus both rofi and rofi-wayland packages are built using Meson.

rofi uses git submodules for libgwater and libnkutils. These libraries are statically linked into rofi, which is suboptimal. Linux distros prefer packaging libraries separately and linking them dynamically, so they can be easily tracked and upgraded separately when a security vulnerability is discovered. However, these libraries don’t make releases, they encourage to use them in the way as rofi uses them. This is not in your hands, so we have to just accept it as it is.

GitHub allows us to download the content of the repository at given commit, branch or (release) tag as a tarball. The problem is that it doesn’t include submodules. That’s (one of?) the reason why the upstream rofi generates own tarballs attached to each release (the other reason is probably pregenerating autohells crap, but I didn’t look at it).

The rofi APKBUILD (recipe for building packages) in Alpine Linux currently doesn’t use this custom tarball (probably for historical reasons), so it’s currently the same as in the rofi-wayland APKBUILD. For this reason we have to write SHA (and source URL) of these two submodules in the APKBUILD and manually keep it in sync. This is subptimal, but since they are rarely changed, it’s not so big deal.

tl;dr Providing release tarballs with included submodules would be beneficial, but it’s not strictly necessary for packaging.

On the other hand, (git) tagging releases is almost must have, basically for any distribution. Also, I would really appreciate setting up CI for this fork, running the build and tests for each commit and pull request.

Alpine Linux strives for small packages, both in terms of number of dependencies and disk size. Thus it’s desirable to split X11 backend and Wayland backend into two packages. Ideally as two shared libraries, but two variants of the rofi executable (one for X11, another for Wayland) is good enough. This is now possible with #31 which I already used in the rofi-wayland aport, so this goal is satisfied.

I haven’t noticed anything else needed for packaging this fork in Alpine Linux. The need for this fork is suboptiomal, obviously, but still better than having no Wayland support. So, thank you a lot for implementing Wayland support into Rofi and maintaining this fork!

lbonn commented 2 years ago

First tarballs https://github.com/lbonn/rofi/releases/tag/1.7.0%2Bwayland1