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

Wael Karram wael at waelk.tech
Tue Aug 16 10:39:03 GMT 2022

On Mon, 15 Aug 2022 19:26:25 +0200
Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:

> 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."  
I have fixed the copyright and identifier, I've also dealt with the .hg
As for the modules and their licensing status, it seems so far that everything
is MIT-licensed.
I'll sit in the evening again and double check, but if that is the case then no
need for mksource hackery I think.

> 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).
There is no point in doing that, I've checked the official docs, it seems as
though packages should be updated in tandem with the core server software - yet
most of them still retain backwards compatibility (the issue is with
forwards-compatibility sometimes).
I propose that this package gets updated and versioned in tandem with the core
prosody software to avoid any issues.
> > 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.
Seeing as this is the simplest way, this is what I opted to do.
> 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.
The modules are all Lua interpreter files, so copying suffices and upstream
doesn't have a better way for organizing or even versioning them.
It's all one big rolling release, and most modules are very small and simple.

> 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.

While reviewing things again though, I have come up on an issue which I didn't
consider before: it seems to all be free software, but some of the modules
might cause issues when it comes to privacy.
For example, there is a captcha module that offers the option to use google or
cloudflare captchas (while also providing an option of a local fallback captcha
for those who opt out of using such services).
Does this mean we'll potentially have to patch some modules and maybe even
delete others altogether?

Kind Regards,
Wael Karram.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-updated-pkgbuild-for-prosody-community-modules.patch
Type: text/x-patch
Size: 1178 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220816/60ea4cf9/attachment.bin>
-------------- 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/20220816/60ea4cf9/attachment.sig>

More information about the Dev mailing list