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