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

Wael Karram wael at waelk.tech
Wed Aug 17 15:44:13 GMT 2022


On Wed, 17 Aug 2022 15:41:43 +0200
Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:

> On Mon, 15 Aug 2022 19:26:25 +0200
> Denis 'GNUtoo' Carikli <GNUtoo at cyberdimension.org> wrote:
> > 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.  
> By patches I meant something like sending a single patch to add the
> prosody-community-modules PKGBUILD in abslibre. 
> 
> If the patch is not pushed (yet) in abslibre and needs modifications,
> it's usually easier for maintainers to review a new version of that
> patch/PKGBUILD instead of having to review patches on top of the first
> PKGBUILD being sent.

I see, then I'll just send in the two different PKGBUILDs for now, once I fix
the issues in both.
> On Wed, 17 Aug 2022 10:20:48 +0300
> Wael Karram <wael at waelk.tech> wrote:
> > Here is the PKGBUILD for the package that'd go in nonprism.
> > I've also attached the whole list of modules that I've excluded.  
> Did you manage to make the PKGBUILD clone a specific mercurial
> revision, or did I miss that? 
> 
> This is important because otherwise users and people building this
> PKGBUILD will expect a specific revision (0.12.1) of the
> prosody-community-modules and will instead get the last revision at the
> time the package was built.
> 
> If the idea is to have the latest revision, this brings several issues.
> 
> Aur has packages that use the latest (usually git) revisions, so when
> users automatically builds them, they get the latest revision at the
> time they build it. 
> 
> Parabola doesn't have something like that so we end up having to use a
> fixed revision at least for the packages we ship. And some Parabola
> contributor(s) really want PKGBUILDS to use known releases.
> 
> If your goal is to always have the latest revision, we can try to find
> solutions for that, like publishing the PKGBUILD in a separate
> repository in abslibre but letting users build it with makepkg.
> 
> In that case the PKGBUILD would also need to be modified to communicate
> that to users. In pcr/omap-u-boot-utils-git/PKGBUILD, there is an
> example that shows how to set pkgver and pkgname for git.
I guess I'll have to figure out the equivalent for mercurial, I think Arch Wiki
had something about it.
> As for the information in modules_requiring_special_treatment, it is
> very useful, so it would be sad to loose it. To avoid that it could be
> added as-is in the PKGBUILD inside comments.
> 
> It also has comments like that inside
> > mod_pubsub_feeds: seems to include unlicensed code.  
> 
> Here if we don't use mksource(), Parabola would end up shipping
> binary packages without mod_pubsub_feeds (as you removed it if I recall
> well), but it would also ship the mod_pubsub_feeds source code.
> 
> So it's probably easier to use mksource() to make sure that Parabola
> doesn't accidentally redistribute code that could make Parabola liable.
> 
> There are also other options for that but they are more complicated.
> 
I've tried the mksource approach now, we'll see if it is enough.
I've attached the PKGBUILD to the email, this is the stricter version that
removes all modules interacting with non-free code of any form (mostly "cloud"
stuff).
> Denis.



-- 
Kind Regards,
Wael Karram.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PKGBUILD
Type: application/octet-stream
Size: 1727 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220817/0de42e7c/attachment.obj>
-------------- 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/20220817/0de42e7c/attachment.sig>


More information about the Dev mailing list