Package Details: smplayer-git 24.5.0.10283.r3.gc817337-1

Git Clone URL: https://aur.archlinux.org/smplayer-git.git (read-only, click to copy)
Package Base: smplayer-git
Description: Media player with built-in codecs that can play virtually all video and audio formats
Upstream URL: https://www.smplayer.info
Licenses: GPL-2.0-or-later
Conflicts: smplayer
Provides: smplayer
Submitter: EndlessEden
Maintainer: willemw
Last Packager: willemw
Votes: 143
Popularity: 0.001201
First Submitted: 2022-07-08 12:54 (UTC)
Last Updated: 2024-07-08 07:23 (UTC)

Dependencies (15)

Required by (7)

Sources (1)

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 Next › Last »

<deleted-account> commented on 2010-12-05 21:28 (UTC)

@ foutrelis In general Allan is right. However, there is a catch. The reason there should be a versioned deps, is for testing purposes. ie, you have tested that your package works with mplayer flavors later than a specific svn version, and can be built and work on top of a specific qt version and later. Why am I saying all these? Because from time to time, there are some idiots here and in the forums, that report as a "bug", some problematic behavior because they still have in their systems qt and/or mplayer svn revisions two years old. Versioned deps are an excellent unavoidable defense, against this type of idiots.

<deleted-account> commented on 2010-12-05 21:23 (UTC)

Nice to know foutrelis. Thank you.

foutrelis commented on 2010-12-05 15:31 (UTC)

@wantilles: Only '=' is allowed in the provides array; '>=' would be invalid in that context. @flamelab: Personally, I'd drop the version from both mplayer and qt. I agree with Allan here [1], even though his message applies better to the binary repos and not the AUR where you can easily edit the PKGBUILD before you build a package. ---- [1] http://mailman.archlinux.org/pipermail/arch-dev-public/2010-January/015206.html

<deleted-account> commented on 2010-12-05 11:28 (UTC)

@syne What do you learn out of this? That not all AUR packages are flawless. You should check each and every one of them, if they are correctly made up to the packaging standards, and not blindly trust them to comply.

<deleted-account> commented on 2010-12-05 11:23 (UTC)

So, flamelab's package is as it should be.

<deleted-account> commented on 2010-12-05 11:23 (UTC)

@syne mplayer-git package is wrong. If you had read the pacman documentation, you would have known that after pacman 3.x, every package that provides another, has to include in the provides array, specific versions, either with "=" or with ">=". A very good way to deal with this, if you build a package that provides another, is to always provide the current (latest) version of that stock package that is in extra, at the time you build the package. So syne, you'd better RTFM next time. PS: There are many packages, even in the official repos (ie extra) that do not comply to this. That does not mean that they are correct. In fact, they need to be corrected.

flamelab commented on 2010-12-05 11:18 (UTC)

Νο, I don't think I will remove it. I support the official svn versioning of mplayer (the one from [extra] mainly) and, thus, I still use the svn versions in the depends.

syne commented on 2010-12-05 10:05 (UTC)

ok, i give, it's much easier just to remove version number from your pkg.

flamelab commented on 2010-12-03 16:09 (UTC)

Well, there is **workaround**: add provides=("mplayer-svn=35000") (for example) in the mplayer*-git package, rebuild it and you will be OK. It wouldn't of course provide *that* particular svn version, but it's *workaround*.

syne commented on 2010-12-03 11:30 (UTC)

does the pkg not work with mplayer versions under 30526? because as you know git-versions don't really match official versions:( plus, it's probably safe to say that everyone's got a mplayer with version over 30526.

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 Next › Last »