[ISSUE] Cmus doesn't respond to playerctl commands

[ISSUE] Cmus doesn't respond to playerctl commands

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

New issue by LinArcX on void-packages repository

https://github.com/void-linux/void-packages/issues/15371

Description:
<!-- Don't request update of package. We have a script for that. https://alpha.de.repo.voidlinux.org/void-updates/void-updates.txt . However, a quality pull request may help. -->
### System

* xuname:  
```
dmesg: read kernel buffer failed: Operation not permitted
Void 5.2.19_1 x86_64 GenuineIntel notuptodate rrDDDFFF
```
* package:  
  cmus

### Expected behavior
When i want to use playerctl commands like: `playerctl play-pause`, the cmus should respond to it properly.

### Actual behavior

### Steps to reproduce the behavior
Install cmus and playerctl.

Edit: actually cmus team was added MPRIS support in version v2.8.0:
https://github.com/altdesktop/playerctl/issues/114

Re: Cmus doesn't respond to playerctl commands

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

New comment by zdtcd on void-packages repository

https://github.com/void-linux/void-packages/issues/15371#issuecomment-542465651

Comment:
`cmus` checks for `elogind-devel` for MPRIS support.

Re: Cmus doesn't respond to playerctl commands

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

New comment by zdtcd on void-packages repository

https://github.com/void-linux/void-packages/issues/15371#issuecomment-542465651

Comment:
`cmus` checks for `elogind-devel` for MPRIS support.

Adding `elogind` to list of cmus's dependency may enrage a lot of people.

Re: [ISSUE] [CLOSED] Cmus doesn't respond to playerctl commands

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

Closed issue by LinArcX on void-packages repository

https://github.com/void-linux/void-packages/issues/15371

Description:
<!-- Don't request update of package. We have a script for that. https://alpha.de.repo.voidlinux.org/void-updates/void-updates.txt . However, a quality pull request may help. -->
### System

* xuname:  
```
dmesg: read kernel buffer failed: Operation not permitted
Void 5.2.19_1 x86_64 GenuineIntel notuptodate rrDDDFFF
```
* package:  
  cmus

### Expected behavior
When i want to use playerctl commands like: `playerctl play-pause`, the cmus should respond to it properly.

### Actual behavior
It doesn't work.

### Steps to reproduce the behavior
Install cmus and playerctl.

Edit: actually cmus team was added MPRIS support in version v2.8.0:
https://github.com/altdesktop/playerctl/issues/114

Re: Cmus doesn't respond to playerctl commands

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

New comment by ailiop-git on void-packages repository

https://github.com/void-linux/void-packages/issues/15371#issuecomment-543183849

Comment:
> `cmus` checks for `elogind-devel` for MPRIS support.
> 
> Adding `elogind` to list of cmus's dependency may enrage a lot of people.

So why make elogind a default build option? Do we have some policy on dealing with optional package dependencies?

It's not easy to keep a balance, as every possible additional dependency may be required by someones use-case, and in the end we'll end up with totally bloated void installations. I suppose this needs to be discussed (if it wasn't already), potentially in the mailing list?

There should perhaps be a way to evaluate more properly every new build option that brings in additional runtime dependencies, and consider maybe opting to not making most of those being on by default.

Another approach could be to keep adding them on demand (only if one requests for enabling one's specific use-case), although this will eventually converge to switching on everything.

Yet another (not mutually exclusive), would be to provide a current-minimal repo that builds every package with all build options disabled.

What do you think?

Re: Cmus doesn't respond to playerctl commands

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

New comment by zdtcd on void-packages repository

https://github.com/void-linux/void-packages/issues/15371#issuecomment-543462256

Comment:
> So why make elogind a default build option? Do we have some policy
> on dealing with optional package dependencies?

Hm, I think `cmus` would be installed on a desktop environment,
and its users are more likely to use a hotkey to interact with cmus
(when working with other applications). I think support `playerctl`
is a sensible default options.

I can't speak for everyone since I'm a `mpd` user,
and I use `mpc` to control it instead.

> Yet another (not mutually exclusive), would be to provide
> a current-minimal repo that builds every package with all build
> options disabled.

By repo, did you mean binary repository?

To disable all options,

```
grep -hr  '^build_options=' srcpkgs/ \
	| cut -d'"' -f2 \
	| tr ' ' '\n' \
	| sort -u \
	| awk -v ORS=',' 'NF{print "~" $0}'
	| sed 's/^.+$/XBPS_PKG_OPTIONS="\0"' >> etc/conf
```

-- 
Danh

Re: Cmus doesn't respond to playerctl commands

[voidlinux-github]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

New comment by ailiop-git on void-packages repository

https://github.com/void-linux/void-packages/issues/15371#issuecomment-543642783

Comment:
> Hm, I think `cmus` would be installed on a desktop environment, and its users are more likely to use a hotkey to interact with cmus (when working with other applications). I think support `playerctl` is a sensible default options.

This is a good example of a conflicting defaults expectation that I was pointing out. I do not see how cmus would be associated with any desktop environment, being a purely terminal-oriented cli utility (and there's always the cmus-remote for controlling it over a unix socket with no external deps). So what's sensible for some population of users will be totally incomprehensible for some other population of users.

Thus my question is more generic than just the case cmu, if we have some policy for dealing with optional build dependencies in general.

> By repo, did you mean binary repository?

Yes I mean an officially published binary repo that builds all packages with minimal dependencies. 

Of course anyone can compile locally with their selection of build opts, but I think it's frustrating for both those that prefer minimal packages and those that need all the bells and whistles.