Re: Maintaining GNU Jami package for Guix

[Marius Bakke <mbakke@fastmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]

Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> writes:

> Dnia 2019-10-31, o godz. 23:26:39
> Marius Bakke <mbakke@fastmail.com> napisał(a):
>
>> Do you have a link to the patches that Jami/pjproject needs?
> You can find patches in the ring-project/daemon/contrib/src/pjproject
> directory from the latest source tarball here:
> https://dl.jami.net/ring-release/tarballs/

I did not find any cURL or GnuTLS patches there.  Maybe I misunderstood
something?

>> It would be great if we could use system versions of GnuTLS and cURL,
>> because otherwise Jami risks not getting security updates.
> A bit unlikely, they update dependencies quickly, but they're slower
> than upstream. Keeping a separate version and updating it paralelly
> will prevent breaking the build process of the modified pjproject
> version. 
>
>> If they really need special patched versions of some libraries, you
>> can do something along these lines to create a
>> cusctm variant:
>> 
>> (define-public gnutls/jami
>>   (hidden-package
>>    (package/inherit
>>     gnutls
>>     (source (origin
>>               (inherit (package-source gnutls))
>>               (patches (append (origin-patches gnutls)
>>                                (search-patches
>> "gnutls-jami.patch"))))))))
> Why can't we just keep paralell version for a package? Like 
> gnutls @ 3.6.7, gnutls @ 3.6.9 etc?   

Both GnuTLS and cURL have stable ABIs.  That means, a package linked
against cURL 7.63 will almost certainly work with cURL 7.66 without
changes (even without recompilation).

There are many reasons not to include multiple versions of a package,
but for cURL and GnuTLS in particular, the main reason is that there are
security fixes in nearly every new version.  Thus, we can only support
the latest one.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]