Package Details: moc-pulse 2.5.2-16

Git Clone URL: https://aur.archlinux.org/moc-pulse.git (read-only, click to copy)
Package Base: moc-pulse
Description: An ncurses console audio player with support for pulseaudio
Upstream URL: https://moc.daper.net/
Keywords: cli music
Licenses: GPL-2.0-or-later
Conflicts: moc
Provides: moc
Submitter: hv15
Maintainer: hv15
Last Packager: hv15
Votes: 13
Popularity: 0.42
First Submitted: 2016-06-26 15:20 (UTC)
Last Updated: 2025-02-10 10:35 (UTC)

Dependencies (25)

Required by (11)

Sources (5)

Latest Comments

1 2 3 4 5 Next › Last »

christoph.gysin commented on 2025-02-12 10:27 (UTC) (edited on 2025-02-12 10:28 (UTC) by christoph.gysin)

Other suggestion can be to make a split package: moc-headers as an extra package which can be installed but not has to be.

This would be against arch principles:

https://wiki.archlinux.org/title/Arch_Linux#Principles "Packages are only split when compelling advantages exist, such as to save disk space in particularly bad cases of waste."

For cases where it happens because someone explicitly adds an older version for some other backwards compatibility issues?

Arch does not support old versions of packages. It would be impossible to add checks for all possible missing features for every package, hence every arch user is expected to keep systems up to date.

dreieck commented on 2025-02-12 09:57 (UTC) (edited on 2025-02-12 09:59 (UTC) by dreieck)

And you can of course request upstream to install headers by default.

This is a nice idea,

That is not a modfication of upstream IMO, rather a bugfix we apply in arch packages.

I do not see it as a bug that headers are not installed to a end user release.

Other suggestion can be to make a split package: moc-headers as an extra package which can be installed but not has to be.

We don't have any moc package that ships moc < 2.4, so I don't see why we need to add extra provides with explicit version numbers.

For cases where it happens because someone explicitly adds an older version for some other backwards compatibility issues?

Anyway, it always helps I think. Which disadvanrage do you see in adding this?

christoph.gysin commented on 2025-02-10 11:10 (UTC)

We don't have any moc package that ships moc < 2.4, so I don't see why we need to add extra provides with explicit version numbers.

And you can of course request upstream to install headers by default. They are needed as build dependency for plugins, so should get installed together with the package. That is not a modfication of upstream IMO, rather a bugfix we apply in arch packages.

hv15 commented on 2025-02-10 10:48 (UTC) (edited on 2025-02-10 10:48 (UTC) by hv15)

Hi @dreieck, I've added the version to the provides. Using makepkg to build asap-chiptunes-player correctly identifies moc-pulse or moc-pulse-svn as dependencies.

dreieck commented on 2025-02-10 10:23 (UTC)

I don't think we should introduce virtual -headers packages. That seems against arch packaging standards. Rather, all moc package variants should ship the headers needed to build plugins against.

Can be a valid statement.

My argument was from the point that generally, Arch Linux packages ship as much as possible upstream (in contrast to debian which does lots of own modifications), and that upstream default does not have the header files included, so moc packages are not expected to have them by default.

Anyway, other issue: asap-chiptunes-player makedepends on moc>=2.4 (this is given in the upstream installation requirements). To have this versioned dependency be able to resolve, can you add =${pkgver} to your provides entry?

Regards!

christoph.gysin commented on 2025-02-09 19:28 (UTC)

I don't think we should introduce virtual -headers packages. That seems against arch packaging standards. Rather, all moc package variants should ship the headers needed to build plugins against.

dreieck commented on 2025-02-09 17:49 (UTC) (edited on 2025-02-09 18:07 (UTC) by dreieck)

EDIT: Oh, you were quicker :-). I forgot to reload this site.
Anyway, maybe adding moc-headers=${pkgver} to the provides array and moc-headers to the conflicts array could still be added -- because they are by default not part of moc, it is advisable to makedepend on them if needed and not makedepend on moc directly.
(Oh, and maybe also add =${pkgver} to the moc provides entry, to allow for versioned (opt)depends on that, too.)

Can you also install moc's include files?

Here is a diff to the PKGBUILD which achieves this -- and it actually is sufficient to build the "offending" plugin:

--- PKGBUILD.orig   2025-02-09 18:34:36.089999830 +0100
+++ PKGBUILD    2025-02-09 18:46:44.953332729 +0100
@@ -28,4 +28,4 @@
             'pulse-native-provider: for using the pulseaudio plugin')
-provides=('moc')
-conflicts=('moc')
+provides=('moc' "moc-headers=${pkgver}")
+conflicts=('moc' 'moc-headers')
 source=("https://ftp.daper.net/pub/soft/${_pkgname}/stable/${_pkgname}-${pkgver}.tar.bz2"
@@ -71,2 +71,5 @@
   make DESTDIR="${pkgdir}" install
+
+  ## Install header files
+  install -Dvm644 -t "${pkgdir}/usr/include/moc" *.h
 }

Regards!

hv15 commented on 2025-02-09 17:03 (UTC)

Hi @dreieck, I've added the necessary headers and have successfully built the ASAP plugin by updating the moc.mk with:

MOC_INCLUDE = /usr/include/moc
MOC_PLUGIN_DIR = /usr/lib/moc/decoder_plugins

dreieck commented on 2025-02-09 14:04 (UTC)

Can you also install moc's include files?

They are required by other software which compile e.g. plugins for moc, see e.g. this issue.

Regards!

hv15 commented on 2024-08-26 15:37 (UTC)

Hi @Megumi_fox, good catch on pipewire-jack, I must have misread the dependency list for it. I'll add libsamplerate as a depends for moc-pulse. Stay tuned!

1 2 3 4 5 Next › Last »