Jan Wielkiewicz <tona_kosmicznego_smie...@interia.pl> writes: > Dnia 2019-10-31, o godz. 23:26:39 > Marius Bakke <mba...@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.
signature.asc
Description: PGP signature
