Package Details: deadbeef-git r11509.b6c2bc326-1

Git Clone URL: https://aur.archlinux.org/deadbeef-git.git (read-only, click to copy)
Package Base: deadbeef-git
Description: A GTK+ audio player for GNU/Linux (devel branch)
Upstream URL: https://deadbeef.sourceforge.io/
Licenses: GPL2, zlib, LGPL2.1
Conflicts: deadbeef
Provides: deadbeef
Submitter: archtux
Maintainer: ToadKing
Last Packager: ToadKing
Votes: 120
Popularity: 0.148092
First Submitted: 2009-08-21 13:16 (UTC)
Last Updated: 2023-11-11 22:15 (UTC)

Required by (45)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 11 Next › Last »

MountainX commented on 2021-09-30 22:48 (UTC)

@ToadKing-thanks again for engaging in the conversation. As an Arch user, I appreciate your efforts to maintain this package.

As far as I know, if the libblocksruntime pkg was removed from AUR, it would give your PKGBUILD a dependency which cannot be satisfied, right? So either way, this PKGBUILD, in its current form, is going to give an error.

In case it helps you decide on a course of action, @MithicSpirit and I both agree it would be preferable to remove libblocksruntime from depends in this PKGBUILD.

(BTW, slightly off topic, but where is the upstream for the latest libblocksruntime? It's not this one? https://github.com/mackyle/blocksruntime)

MithicSpirit commented on 2021-09-30 22:36 (UTC)

@MountainX I'd think pacman would be smart enough to not attempt to install duplicate dependencies when one is already provided by another (especially when they also conflict), but I guess not. In that case I guess it would be preferable to remove libblocksruntime from depends.

ToadKing commented on 2021-09-30 22:01 (UTC)

There used to not be a conflict, it was only when libdispatch was updated to provide its own libblocksruntime when it appeared. IMO the issue should be fixed in the library packages, either by separating libblocksruntime again and updating the old package, or by just removing the old outdated libblocksruntime. Again, the current version of it on AUR is very outdated and shouldn't be used in the first place.

MountainX commented on 2021-09-30 21:59 (UTC)

@MithicSpirit-in my discussions with Arch devs about PKGBUILDs, no one has ever suggested that it is a good practice to create a PKGBUILD which results in conflicts. You don't throw everything in there and let the end user sort it out. As a package maintainer, you provide a working PKGBUILD. But I'm not the maintainer of this package, and I don't claim any special expertise. I've said my 2 cents. If this gets fixed or not is not up to me.

MithicSpirit commented on 2021-09-30 21:34 (UTC) (edited on 2021-09-30 21:34 (UTC) by MithicSpirit)

@MountainX IIRC in the Arch Packaging Guidelines (which afaik extend to the AUR) you're supposed to include every single dependency and not rely on transitive dependencies, which I believe includes items in the provides array.

MountainX commented on 2021-09-30 21:20 (UTC)

@ToadKing - thanks for replying.

the libblocksruntime package was left unmaintained and now the libdispatch package also provides them.

That tells me that libblocksruntime should be removed from the dependencies in the PKGBUILD. Until that is done, installing this package gives an error and requires manual intervention (e.g., the user edits their own PKGBUILD). That's my 2 cents on it.

ToadKing commented on 2021-09-30 21:14 (UTC)

libblocksruntime and libdispatch are separate packages on many other distros so it initially worked that way here as well. However the libblocksruntime package was left unmaintained and now the libdispatch package also provides them. I'm not sure if that's the correct way to do things but since both packages are in the AUR there's not really an official consensus on them. Regardless, you shouldn't be using the current libblocksruntime package on AUR since it's very out of date and should just use libdispatch instead, which provides it.

MountainX commented on 2021-09-30 21:10 (UTC)

@MithicSpirit-wouldn't the correct course of action be for the maintainer to correct the PKGBUILD? Why would a valid PKGBUILD include conflicting packages? (I'm not asking how to fix my problem, I'm asking for anyone who wants to install the package without editing the PKGBUILD.)

MithicSpirit commented on 2021-09-30 20:33 (UTC)

@MountainX aur/libdispatch provides libblocksruntime, so the correct course of action would be to replace libblocksruntime with libdispatch if you wish to install this package.

MountainX commented on 2021-09-30 20:13 (UTC)

These dependencies are listed in the PKGBUILD:

depends=('alsa-lib' 'hicolor-icon-theme' 'jansson' 'libblocksruntime' 'libdispatch')

However, 'libblocksruntime' and 'libdispatch' are in conflict.

Package conflicts found:
-> Installing libdispatch will remove: libblocksruntime

Therefore, using this package seems to require editing the PKGBUILD first. Can the maintainer fix the PKGBUILD or suggest what the intention is for listing conflicting dependencies?

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 11 Next › Last »