Search Criteria
Package Details: mpdris 1.2.0-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/mpdris.git (read-only, click to copy) |
|---|---|
| Package Base: | mpdris |
| Description: | A MPD client implementing the dbus MPRIS standard written in rust |
| Upstream URL: | https://github.com/jasger9000/mpDris |
| Licenses: | MIT |
| Conflicts: | mpdris-bin, mpdris-git |
| Provides: | mpdris |
| Submitter: | jasger |
| Maintainer: | jasger |
| Last Packager: | jasger |
| Votes: | 1 |
| Popularity: | 0.22 |
| First Submitted: | 2025-02-09 16:50 (UTC) |
| Last Updated: | 2025-02-15 14:35 (UTC) |
Dependencies (6)
- dbus (dbus-gitAUR, dbus-selinuxAUR)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc11-libsAUR, gcc-libs-snapshotAUR)
- glibc (glibc-gitAUR, glibc-linux4AUR, glibc-eacAUR)
- mpd (mpd-smbclientAUR, mpd-server-minimalAUR, mpd-gitAUR, mpd-sacdAUR, mpd-minimalAUR, mpd-light-pulse-ffmpegAUR)
- cargo (rustup-gitAUR, rust-nightly-binAUR, rust-gitAUR, rust-beta-binAUR, rustup-stubAUR, rust, rustup) (make)
- libsystemd (systemd-libs-fmlAUR, systemd-libs-selinuxAUR, systemd-libs-gitAUR, systemd-libs) (optional) – run mpdris as a service
Latest Comments
jasger commented on 2025-02-15 22:01 (UTC)
You're correct, I can also reduce all the conflicts to just 'mpdris' since they all provide 'mpdris'.
Will do with the next update.
m040601 commented on 2025-02-15 21:18 (UTC) (edited on 2025-02-15 21:19 (UTC) by m040601)
By default the PKGBUILD "XXX" doesnt need this. That is for the PKGBUILD variants "XXX-bin" and/or "XXX-git". It is their job to say that.
jasger commented on 2025-02-11 16:29 (UTC)
Sorry, I wasn't clear on that. I meant the repo as a whole which has been around since 6 months. I was also referring more to the config file, which if I change its name or path would basically mean a v2.0.
I'll change the description together with the next update because I don't think it's worth making whole new pkgrel just for that change.
m040601 commented on 2025-02-10 22:23 (UTC)
It is only 1 day old. I dont think that many people have even found it. That is why I pestered you now so much about the PKGBUILD name. When it is old on the AUR, then it will be too late to change the name.
At least you can change that to
jasger commented on 2025-02-10 20:03 (UTC)
@m040601 so I've gone ahead and made a PKGBUILD for the -git and -bin version.
Thanks for the naming suggestions, but I think unless I get a spontaneous epiphany I'll probably stick with the name.
I didn't actually know that there was a package in the main repo, I thought I had looked.
I definitely understand the issue with confusing the file names, however since the package is public, I'm kind of limited as to what I can do about it without introducing breaking changes and making everyone's installs not work anymore.
I'm now going to focus on making a proper man page and an example config.
I currently also have an open pull request for one of my dependencies (https://github.com/dbus2/zbus/pull/1253) which I'd definitely want to include with the next release.
m040601 commented on 2025-02-10 15:01 (UTC) (edited on 2025-02-10 15:05 (UTC) by m040601)
Some more feedback about the logs and desktop. Hope that with enough polish and votes your tool can make it to an official Arch package.
First the logging.
That logging that you, as a developer, want spit to stdout or send to journalctl.
There is already so much stuff there nowadays.
You just want to play a song. And then a giant soup to fish for the really helpfull stuff. Pipewire, Dbus, mpd, alsa, mpris, all dropping stuff into that soup.
So much useless crappy unnecessary by default. Stuff there related to dbus/pipewire, when you have no camera or bluetooth for example. Yes, you can filter/customize/disable this/that, but is only more work for the end user.
Was it an error ? Or was it just not supported ?
Even if the unit is correctly labelled, it is easy as an human to skip the really important stuff you are fishing for.
Then you miss the "mpd" and "mpris" really important messages in that big soup.
Is it a problem caused by the "mpris helper" tool itself ? Or is it a problem with my DBUS ? Or only my python-dbus ? Etc.
I liked that you seem to care about the logs. Keep doing that work.
Make sure to write good informative message sentences, with the uniq tool name inside it. Not just the "unit" name.
Give the user the ability to choose more/less verbose/debug/info output (-v, -vv, -vvv) etc.
Now second about the "desktop".
I know that this dbus/intercommunication/desktop thing must not be easy for a developer.
I actually hate all that polkit, rtkit, xdg-portals, and non essential dbus crap from freedesktop.org. The only one I really find usefull is actually mpris. The idea that is. Not the way it is implemented.
I see a lot of developers lately, making tools too tightly coupled to dbus. Assuming the user has a "full desktop" like KDE or Gnome. With all that polkit/rtkit/dbus crap. Making it impossible to use the tool without installing that crap.
Please dont ever make that mistake as a developer.
I, as an end user, might not be running a desktop. I might not even start X. Or wayland. And I also can play music and use mpd.
m040601 commented on 2025-02-10 14:04 (UTC) (edited on 2025-02-10 15:15 (UTC) by m040601)
Thanks ! Nice to know you care about feedback from end users.
These are all very valid points.
The thing is everybody wants to stuff the word "mpd" and "mpris" in the name. And everybody forgets that everybody else is also doing the same. It is obvious that the developer himself understands which is his and which is the other.
Apropos. Even I forgot to mention in my previous comment yet another one. You see how easy it is to forget and confuse them ? The one from the japanese guy written in go. |t is an Arch official package.
$ pacman -Qi mpd-mpris
$ pacman -Ql mpd-mpris
Now about the name thing.
I can only give you my perspective as an end user.
It's annoying having things with the similar name to choose from. I want to quickly remember which one is "that good one". Which one uses python ? Rust ? Etc.
Some months later I have another computer or a raspberry to install mpd. Because I dont live in the AUR everyday, I end up forgetting which one was the "good one" and why did , "I", choose it instead of the other one. Because the names are similar, I end up having to do all the "work" again. Checking which github repo is healthy, which PKGBUILD is well maintained on the AUR etc.
My only personal advise is to choose some really unique word. Like a little bit of extra salt or pepper. That makes your tool and PKGBUILD really stand out. BOTH in github AND Aur.
I can understand that you might want the words "mpris" and "mpd" in the name. But I really dont have any good ideas. Out of the blue:
The only thing I know is that when people choose better funny uniq names, I remember better.
Ohhh .. .that "XYZ" is the buggy one from the french guy, that doesnt care about the docs. Forget it. Ohhh .. .that "XYZ" is the bloated electron thing from the chinese guy. Block it. Ohhh .. .that "XYZ" is the go/rust one from the japanese guy. Bookmark it.
You are correct. Technically this is true. But humanely it is another different story.
I have so much stuff to care about in ~/.config and ~/.config/systemd/user/xyz.service
And then I want to quickly find, edit, configure, start, stop etc.
And cant remember which one was which because of similar names.
Easy to confuse because of single letter "mpdmpris" "mpdris".
Which one is the one with hyphen "mpd-mpris" or "mpdmpris" ?
Inconsistencies in CAPS/minors, sometimes is "d" sometimes is "D" , mpDris/mpdris.
Was that example xyz.service created by me by hand ? Or shipped by the tool.
And then its late you are tired and confuse "mpv-mpris" with "mpd-mpris"
And then you even have the other mpris control tools (not related to mpd) with also confusing names , "mpris-ctl" "mprisctl" etc.
And then people forget to use good "Description" tags on the AUR.
jasger commented on 2025-02-10 11:54 (UTC) (edited on 2025-02-10 12:00 (UTC) by jasger)
Hey, thanks for the comment.
I'll be sure to add a -bin (and -git) version later toady, I kind of forgot to include it.
I know of the naming problem, however I couldn't think of a better one, which is why I just went with the base name.
I considered mpdris-rs but that would make it seem like mpdris2-rs is a successor to my package even though they're completely unrelated.
If you have another suggestion please let me know.
The package shouldn't actually conflict with any of the others since they all use different install paths/directories.
If you mean that you can't run them all at the same time, the PKGBUILD wiki entry isn't entirely clear on that.
It writes: "An array of packages that conflict with, or cause problems with the package, if installed."
I interpreted that "if installed" means that runtime is completely irrelevant, hence no conflicts.
I mean I'm not really actively competing for users or anything. But if you really want to compare:
My package is as far as I can see basically on par with mpdris2-rs in terms of disk usage (mine's 100KiB smaller, while mpdris2 wins outright 2.11MiB -> 90.73KiB).
RAM is a bit more divided with mpdris2-rs using 5.3MB, mine with 4.1MB and mpdris2 with 39MB.
And performance in terms of speed is basically irrelevant for this kind of application, but I will say that my implementation uses less cloning than mpdris2-rs to expose the data to dbus clients.
The only real standout I have over the other packages is that I manually implement cover searching but that's already detailed in the README.
Whoops, forgot about that, I had actually planned to make one since I implemented a config.
You're very likely running a MPRIS client that checks if the TrackList and Playlists interface are exposed/implemented by looking at one of its properties.
So yes, you're correct, nothing to worry about. I'll look into if I can suppress that specific warning since its nothing the user should worry about.
m040601 commented on 2025-02-10 01:45 (UTC) (edited on 2025-02-10 02:10 (UTC) by m040601)
Thanks for this new tool and the PKGBUILD. I'm eager to test this one. I've been testing all others in the AUR for a long time. Not very satisfied.
Since you already release precompiled binaries on github, it would be extremelly usefull if you could also provide a "-bin" PKGBUILD on the AUR. That (binary) release on github should be a tar.gz with the binary, plus LICENCE, README and systemd.service.
Big advice.
You should rename this PKGBUILD on the AUR. Check the AUR naming guidelines. Dont expect your tool is the only one with that name.
Yours:
There is already another one also in Rust,
As you can see it is customary to append "-rs" or "-rust" to AUR rust tools.
If you search you will find others even older in python,
It takes time to distinguish one from the others.
Why not make life simple and not confusing for AUR users searching for tools ?
Dont save characters on the "Description". Say it's written in Rust.
Make sure if the binary clashes conflicts with others with the same name to use the tag "Conflicts"/"Provides".
Explain in the README why is it different/better than the others.
Provide an example sample.mpdris.conf. You talk about it on the README, but you dont provide one.
A final question. I always get these kind of annoying cryptic messages. Never sure if these are errors or can be ignored. Nobody explains in the README's. Everybody assumes the end user is an expert MPRIS/DBUS developer.
My guess is these messages, in your case, just mean that some kind of "functionality" related to Playlists/Tracklist is not yet implemented on your tool.
Am I correct ? Thanks in advance.