Arch Linux

IIUC the dependency on wlroots was introduced because bemenu depends on the wlr-layer-shell protocol which is specific to wlroots, see https://github.com/archlinux/svntogit-community/commit/922823be447d038894722c14f0075f72106117d9#diff-37538beb61ff63edebbf735dfcf39e5d732f49183d6beb097169d971875ca422 and https://github.com/Cloudef/bemenu/issues/79#issuecomment-572867783 for context. Unless other Wayland compositors have added support for wlr-layer-shell as well, the dependency of bemenu on wlroots seems to make sense to me to document that the application will not work properly with other compositors. Or is there something else I am missing here?

wlr-layer-shell is not a private wlroots protocol. It's a public protocol developed by wlroots. That means: even if the protocol was written by wlroots developers, other compositors can implement it. For example, Mir and a Weston fork have it.

I don't think it's a good idea to document that a client requires a compositor feature by depending on a particular compositor library.

In any case, a build-time dependency doesn't make sense.

The wlroots dependency stays; try running bemenu in [community]/weston, for instance. When upstream announces broader compatibility, then we'll see.

Try running bemenu in https://aur.archlinux.org/packages/mir/.

X11 clients don't depend on xorg-server. I don't see why Wayland clients would be different. Also this doesn't match the rest of the Arch Wayland packages like grim, slurp, swaybar, swaybg, swayidle, wf-recorder, xdg-desktop-portal-wlr and so on.

BTW, I'm the Wayland and Weston maintainer. Please trust me when I say this doesn't make sense.

From a Wayland architectural point of view, I'm sure it doesn't. However, I feel it's important to make it clear that it absolutely will *not* work on, say, Weston--which is where I initially tested its wayland support before going down a rabbit hole to figure out exactly why it didn't work only to discover that it only works in wlroots-based not-window-managers...and then had to port my apparently-partially-incompatible-with-sway i3 configuration to sway just to test its basic functionality.

If I rename bemenu-wlroots bemenu-wayland and remove the dependency, then I fully anticipate spurious bug reports: "tried it in <my favorite not-window-manager>, didn't work, broken package, plz fix".

I suppose I could add an optdepends: "wlroots-based not-window-manager: run it in one of these if you want the thing to actually function"...if I thought most people actually looked at pacman's output like they should. Would that be a satisfactory solution?

No. wlroots optional dep is wrong. bemenu works on non-wlroots-based compositors like Mir and KWin. The wlr protocols are not tied to the wlroots library.

Don't pull a whole compositor library, which also comes with its own dependencies, just to mean that it may not work on all Wayland compositors.

*Some* non-wlroots-based compositors. Not all. *Which* not-window-manager you pick determines what programs you can run for some insane reason, which means that it's necessary to communicate the flavor that it's compatible with.

Will optdepends=('wlr-layer-shell-compatible compositor: run in one of these for it to actually work') be satisfactory?

>If I rename bemenu-wlroots bemenu-wayland and remove the dependency, then I fully anticipate spurious bug reports: "tried it in <my favorite not-window-manager>, didn't work, broken package, plz fix".

Submit evidence

>*Some* non-wlroots-based compositors. Not all. *Which* not-window-manager you pick determines what programs you can run for some insane reason, which means that it's necessary to communicate the flavor that it's compatible with.

Why are you even maintaining this package if you're just going to flame Wayland? Let someone else do it.

This package should not depend on wlroots. It should not optdepend on wlroots. It should not mention wlroots at all. This is a statement of fact, delivered to you by the experts.

I was under the impression that the Arch policy was to not take misjudged downstream decisions like other distributions might do. I was under the impression that Arch policy was to follow upstream as closely as possible.

Am I mistaken?

I'd intuitively expect this sort of thing to be a post_install message or something.

Optdepends is not a suitable location for adding virtual provides that don't exist anywhere and are solely there for sending messages to the user. It is a suitable location for adding a valid dependency linkage to another package or virtual package that actually exists and can be resolved by a machine, alongside a human readable description.

A suitable possibility would be:

optdepends=('wlroots: compositor that actually supports bemenu')

Or adding a special provides entry to each compositor that implements wlr-layer-shell and then depending on 'wlr-layer-shell-implementation' or idk something like that.

Personally I'd stick with the post_install message.

"Warning: many wayland composite don't support wlr-layer-shell, thus bemenu' won't work. Try a wlroots based one, or mir or kwin, as they are known to work"

Yeah, a post_install message sounds completely fine by me.

A provides entry seems over-engineered, and won't accommodate for all cases (e.g. running via waypipe).

Drew, Simon,

Please keep thinly veiled authority arguments, bad faiths arguments and other unconstructive nonesense out of the bugtracker.

Thank you.

Drew, it's part of the overall bemenu package, which also supports X11 and ncurses. I'd be griping about X11 if I encountered programs that ran in GNOME, LXDE, and herbstuflwm, but refused to run in KDE or i3 because Xlib didn't just work wherever.

eschwartz and emerson, I'll change it and add a post_install message later today.

Tell that to your own people, Foxboron.

>*Which* not-window-manager you pick determines what programs you can run for some insane reason, which means that it's necessary to communicate the flavor that it's compatible with.

This is embarassingly bad form from Arch here. This package is wrong, and needs to be fixed. This is not a thinly vieled critism, but an explicit critism: this is a bad look for Arch. What's unconstructive is a Linux distro ignoring the advice of and picking fights with upstream.

For the record -- I did only mention the provides entry as a devil's advocate argument. It's the only possibility I could see for validly encoding this information as pacman dependency metadata, but that's not the same as recommending it....

I agree it is over-engineered and flaky.

> What's unconstructive is a Linux distro ignoring the advice of and picking fights with upstream.

The only one picking fights is you.

In-case it's not obvious.

>Submit evidence

Is not an advice.

>Why are you even maintaining this package if you're just going to flame Wayland? Let someone else do it.

Is not an advice, and frankly rude. You know just as well as me that is rude towards people that dedicate their own free time to contribute.

>This package should not depend on wlroots. It should not optdepend on wlroots. It should not mention wlroots at all.

Is an advice, but could be worded better.

>This is a statement of fact, delivered to you by the experts.

Is not an advice either. 'ab auctoritate' - I don't need to tell you how this works.

I shouldn't need to tell you this Drew, people have told you plenty of times.

I'm sorry for calling the design "insane", but I stand by the critique that when a Wayland program with all its runtime dependencies installed, when run in Wayland, the compositor should say "Oh, a program wants to show a window? Great!" as window managers do in X. I'm sure that there are technical reasons for this, but frankly I don't have time to do a dive into architecture and design documentation today. As I said earlier, I'm replacing the dep. with a post-install message and renaming the package later today.

Edit: accidentally a word

Suit yourself. It's your broken distro, not mine. I'm just here because I saw Ivy being disrespectful of Simon's input and being stalwartly wrong, and I won't stand for that.

Package has been renamed, dependency removed, and a post-install/post-upgrade message added to draw user attention to the pseudodependency.

emersion, I want to be clear that I absolutely respect your work and advice. Any rudeness arose exclusively from frustration, and so for any rudeness on my part, I'm sorry once again.

Closing as implemented.