[Dev] [prosody-community-modules] proposed package for prosody's modules

[Denis 'GNUtoo' Carikli]

On Thu, 11 Aug 2022 10:26:40 +0300
Wael Karram <wael at waelk.tech> wrote:

> Hello,
Hi,

> Currently anyone using prosody on Parabola will most likely have to
> download packages from the source repository to get full
> functionality in prosody (reliant on their community modules).
> I propose this package as a solution to that which allows packaging
> the same modules through the distro's repositories instead.
> 
> I've attached the PKGBUILD I came up with and started to vet the
> source's licensing.
> On the latter issue it seems that almost everything is licensed under
> the MIT license, but I want to check all modules to make sure such is
> the case (I've asked on the prosody support channel and the
> recommended I double-check just in case).
A way to deal with that would be to use mksource() to only include the
source code that you audited for licensing. This way we could include
the work right now without waiting for it to be completed.

You could then send subsequent patches to add more modules.

> # Maintainer: Wael Karram <wael at waelk.tech>

If you did the PKGBUILD yourself, and that you want to maintain it,
using something like is better since it helps clarifying the license:
> # Copyright (C) 2022 Wael Karram <wael at waelk.tech>
> # SPDX-License-Identifier: CC0-1.0
> # Maintainer: Wael Karram <wael at waelk.tech>

If you want everybody (you included) to maintain it, the following can
be used instead:
> # Copyright (C) 2022 Wael Karram <wael at waelk.tech>
> # SPDX-License-Identifier: CC0-1.0
> # Maintainers: Parabola hackers <dev at lists.parabola.nu>

> pkgname=prosody-community-modules
> pkgver=0.12.1
> pkgrel=1
> pkgdesc="Prosody community modules."

The README has the following:
> Community repository for non-core, unofficial and/or experimental
> plugins for [Prosody][]. [...]
> 
> There are lots of fun and exciting modules to be found here, we know
> you'll like it.  However please note that each module is in a
> different state of development.  Some are proof-of-concept, others
> are quite stable and ready for production use.  Be sure to read the
> wiki page of any module before installing it on your server.
I think it is important to indicate that some of the modules are
experimental or even worse (work in progress / proof of concept) in the
pkgdesc, otherwise users might have different expectations of the
modules quality.

> arch=('any')
> url="https://modules.prosody.im/"
> license=('MIT')
> depends=('prosody')
> makedepends=('mercurial')
> source=("hg+https://hg.prosody.im/prosody-modules/")
Here we download some source, but we somehow need to tell mercurial to
fetch a specific version (the one that corresponds to 0.12.1).

> sha1sums=('SKIP')
> 
> package() {
> 	mkdir -p "${pkgdir}/usr/lib/prosody/modules/"
> 	cp -r "${srcdir}/prosody-modules/" \
>             "${pkgdir}/usr/lib/prosody/modules/" 
> }
There is some issues with that approach. We end up with a
/usr/lib/prosody/modules/prosody-modules/.hg directory.

A way to deal with that would be to at least delete that directory
after the copy.

I'm also not sure if just copying the directories is the best way to do
proper packages, but given that some of the modules are experimental
or a proof of concept, if the way it is packaged works, that is probably
good enough.

PS: Note that it is also possible to send patches for review. This way
    we can reuse your commit message, so if you have interesting things
    to add there they get included in the commit.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220815/8b4fea6a/attachment.sig>