Package Details: mpv-git 0.39.0_13_g2c5928e518-1

Git Clone URL: https://aur.archlinux.org/mpv-git.git (read-only, click to copy)
Package Base: mpv-git
Description: Video player based on MPlayer/mplayer2 (git version)
Upstream URL: https://mpv.io
Keywords: media player video
Licenses: GPL-2.0-or-later
Conflicts: mpv
Provides: libmpv.so, mpv
Submitter: rpolzer
Maintainer: qmega
Last Packager: qmega
Votes: 225
Popularity: 0.170460
First Submitted: 2012-12-04 09:21 (UTC)
Last Updated: 2024-09-24 06:58 (UTC)

Required by (409)

Sources (2)

Latest Comments

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 22 23 .. 38 Next › Last »

qmega commented on 2017-04-27 22:14 (UTC)

@ThrowAwayNo_1: Currently I only have ffmpeg as a hard depend because that's the only thing that you can't build mpv without. There is a script that sets the dependencies of the generated package to what it actually depends on, so in my personal install (and yours too, if you installed it), libxss is a dependency. If I added it as a default dependency, someone using mpv on a Wayland-only machine, or a headless machine using --vo=image or audio only or something, would have to edit the PKGBUILD to remove it every time if they wanted to avoid installing and linking against a ton of X11 libs. Granted, most people using this package are probably using X11, but trying to guess at that balance with all the optional dependencies strikes me as a losing battle. The way it is now, everyone has to figure out their optional dependencies the first time (unless everything they need is already installed), but then you pretty much never have to worry about it again, except in the rare occasion a new dependency is added for a feature you already used that you don't already happen to have installed. (I guess that's what happened to you here.) About optdepends, see the comment I just pinned.

qmega commented on 2017-04-27 22:00 (UTC)

I've gotten a lot of requests to add various optional dependencies to optdepends, so I'm pinning an explanation of why I don't do that. I'm still very much open to suggestions on how to improve the situation; I just don't want to answer the same question again and again. TL;DR: Basically, mpv's optional dependencies aren't really optdepends the way the packaging system sees them. Either they were linked against at build time, and mpv won't run without them (hard depend), or they weren't, in which case even if you install them they can't be used until you rebuild mpv. An optdepend tells the packaging system that you can freely install or uninstall it and you will just get/lose the associated optional functionality. Although mpv has many optional dependencies, they don't work like that. They're optional at compile time, but once you've built the package they're either hard dependencies or not dependencies at all. For example: Lua scripting support. If you don't have a supported Lua interpreter installed when you build, your copy of mpv will not support Lua scripting, even if you install Lua later. And if you build with Lua support, uninstalling Lua will render your mpv unable to run entirely, not just disable Lua support. There is a script included with this package that detects what libraries your build is linked against and sets those as (hard) depends when creating the package, so the package you install accurately reflects its dependencies. It might be nice if you were presented with a list of optional dependencies to choose from before building the package for the first time, but I'm not aware of a decent way to do that - user interaction in the PKGBUILD feels nasty, and I definitely don't want any interaction required after the first build. As a compromise, I have a message on install that mentions this issue, but I have it only on the first install to avoid annoying people. This system is certainly far from ideal, but I haven't thought of anything better. The way it is prevents dependencies from getting out of sync, and allows everyone to use whichever optional features they want without having to install a bunch of stuff they don't or edit the PKGBUILD every time. The price is that you have to figure out which extra packages you need the first time you install, but at least you only have to do that once. If anyone can think of a better system, I'm all ears.

ThrowAwayNo_1 commented on 2017-04-26 02:52 (UTC) (edited on 2017-04-26 03:02 (UTC) by ThrowAwayNo_1)

Could you consider add libxss to the list of dependencies? Currently mpv needs it for X11 video output: the command `mpv -vo help` does not show the X11 options if this package is built without libxss, and mpv won't play any video file under X. Please at least add it to the list of optional dependeicies.

qmega commented on 2017-04-02 00:56 (UTC) (edited on 2017-04-02 01:07 (UTC) by qmega)

I decided not to switch back at the time because mpv's releases are pretty much arbitrary git snapshots, and mpv built from master identifies itself by a commit, not the last or next version, so I figured a release-based version still wouldn't mean much. Also, the releases aren't tagged on master, but on a separate branch with extra merge + version commits, so the version tag isn't actually reachable from HEAD, and getting the latest tag has always been a little "interesting". (I never really liked just grabbing the latest tag - it wouldn't give you the tag you wanted if e.g. fixes were backported to an old release.) I don't feel very strongly about this, so I'll reinstate some kind of release-based pkgver for now, but I wonder if a date-based version format would be more appropriate. What you really want to know when you look at the version is how out-of-date it is, right? The date you built it or the date of the last commit would be better indicators of that than release numbers, which for mpv are somewhat arbitrary and irregular. Opinions?

WorMzy commented on 2017-04-01 23:18 (UTC)

This package used to use a similar pkgver (see https://aur.archlinux.org/cgit/aur.git/commit/?h=mpv-git&id=9643c547576c6036bea0c01799d1dc5a5bb0c67f ), but was removed because upstream stopped making releases, and the package in community/ switched to commit versioning. I'd say there's a good argument for switching back to a more descriptive pkgver now.

escondida commented on 2017-04-01 21:37 (UTC)

I'd like to suggest using the following pkgver(), which would provide a more informative version number along the lines of "0.24.0.r189.gdc7d71fc8e", where r189 is revisions since last tag and everything preceding it is the tagged version number. pkgver() { cd mpv tag="$(git tag -l --sort=version:refname | sed -n '$p')" printf '%s.r%s.g%s' \ $(echo $tag | sed 's/^v//') \ $(git rev-list --count "$tag"..HEAD) $(git rev-parse --short HEAD) }

qmega commented on 2017-01-07 02:17 (UTC) (edited on 2017-01-07 02:22 (UTC) by qmega)

Can't reproduce, but based on your error my guess is your python / python-docutils packages are mismatched since the Python 3.6 upgrade, so you're running python 3.6 with docutils in /usr/lib/python3.5 or python 3.5 with docutils in /usr/lib/python3.6. A full system upgrade with up to date mirrors should fix it. If not, check your versions of each package to be sure: latest as of this writing are python 3.6.0-1 and python-docutils 0.13.1-2 (obviously you need both installed, but as they're makedeps I'm assuming you do).

thelongdivider commented on 2017-01-05 06:58 (UTC)

Anyone else having this problem? Traceback (most recent call last): File "/usr/bin/rst2man", line 21, in <module> from docutils.core import publish_cmdline, default_description ModuleNotFoundError: No module named 'docutils' Build failed -> task in 'rst2man' failed (exit status 1): {task 140156037857856: rst2man mpv.rst -> mpv.1} ' /usr/bin/rst2man --strip-elements-with-class=contents ../DOCS/man/mpv.rst DOCS/man/mpv.1 ' ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build mpv-git.

qmega commented on 2016-12-01 03:43 (UTC)

@Soukyuu: That's been asked a couple times before. Here's what I said last time: (TL;DR: They aren't really optdepends the way the packaging system sees them. Either they were linked against at build time, and mpv won't run without them (hard depend), or they weren't, in which case even if you install them they can't be used unless you rebuild mpv. The situation isn't ideal, and I'm open to ideas.) An optdepend tells the packaging system that you can freely install or uninstall it and you will just get/lose the associated optional functionality. Although Lua support is an optional dependency for mpv, it doesn't work like that. If you don't have it installed when you build, Lua support won't be there, even if you install Lua later. And if you build with Lua support, uninstalling Lua will render your mpv unable to run. If you have a compatible Lua installed when you build mpv, it will be picked up and will be a hard depend of the generated package (as it should be, because the package won't work without it). As a compromise, the last time this was asked I added a message on install that addresses this issue and specifically mentions Lua, but I have it only on the first install to avoid annoying people. Here's also what I said last time about the auto-detecting dependencies thing: I know the dependency system is non-ideal, but I haven't thought of anything better. The way it is prevents dependencies from getting out of sync, and allows everyone to use whichever optional features they want without having to install a bunch of stuff they don't or edit the PKGBUILD every time. The price is that you have to figure out which extra packages you need the first time you install, but at least you only have to do that once. If you can think of a better system, I'm all ears.

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 22 23 .. 38 Next › Last »