Package Details: deadbeef-git r11790.7d26d35fc-2

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: zlib, GPL-2.0-or-later, LGPL-2.1-or-later
Conflicts: deadbeef
Provides: deadbeef
Submitter: archtux
Maintainer: ToadKing
Last Packager: ToadKing
Votes: 122
Popularity: 0.69
First Submitted: 2009-08-21 13:16 (UTC)
Last Updated: 2025-03-31 06:46 (UTC)

Required by (45)

Sources (1)

Latest Comments

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

MithicSpirit commented on 2021-09-30 23:28 (UTC) (edited on 2021-09-30 23:32 (UTC) by MithicSpirit)

@MountainX Just did some testing with a localrepo+docker and pacman does manage this correctly, so the issue you're experiencing is likely with your AUR helper. The results are as follows:

  • If I attempt to directly install deadbeef-git then pacman does installs libdispatch and not libblocksruntime (no error);
  • If I install libblocksruntime first, then deadbeef-git pacman gives me the following prompt :: libdispatch and libblocksruntime are in conflict. Remove libblocksruntime? [y/N]. Responding "n" errors and exits (as expected), and responding "y" removes libblocksruntime before installing deadbeef-git and libdispatch (no further warnings/errors);
  • If I attempt to install both libblocksruntime and deadbeef-git at the same time pacman states warning: removing 'libblocksruntime' from target list because it conflicts with 'libdispatch' and continues installing deadbeef-git and libdispatch but not libblocksruntime (no further warnings/errors).

MithicSpirit commented on 2021-09-30 23:08 (UTC) (edited on 2021-09-30 23:08 (UTC) by MithicSpirit)

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.

~@MountainX

If you're using makepkg (which is the official way to install stuff from the AUR) then it will always give a warning since it does not check the AUR for dependencies afaik. As for AUR helpers, it will depend on whether or not that specific helper checks the provides array when looking for dependencies; in the case that it does check provides, it will find that libdispatch does provide libblocksruntime and likely not run into an error.

Also, I just checked your output again and it doesn't seem like it was necessarily an error and rather just a prompt on whether you want to remove the other package (if it did error out maybe you need to pass/unpass a flag to allow interactive input).

ToadKing commented on 2021-09-30 23:00 (UTC)

@MountainX The dependencies can still be satisfied without the libblocksruntime package. libdispatch provides libblocksruntime so all the dependencies will still work. The version of the runtime it builds is in the libdispatch source: https://github.com/apple/swift-corelibs-libdispatch/tree/main/src/BlocksRuntime

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.

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