unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Adonay Felipe Nogueira <adfeno@openmailbox.org>
To: guix-devel@gnu.org
Subject: Re: Continuing the work on the recipes related to GNU Ring
Date: Fri, 31 Mar 2017 16:05:23 -0300	[thread overview]
Message-ID: <87o9whferw.fsf@openmailbox.org> (raw)
In-Reply-To: <87inmwrx5t.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 26 Mar 2017 15:21:34 +0200")

About sending patches for each package definition separatedly: Will do!
:)

However, I'd like to refrain from doing it now while the package's
specific configure/make/build options in their "rules.mak" files aren't
addressed clearly. This is an ongoing discussion at:
[[http://lists.gnu.org/archive/html/ring/2017-03/msg00005.html]].

Some people contributed with useful information. However, the custom
options for pjsip/pjproject are still somewhat unclear for me (except
for the `--with-ssl=gnutls` option, which is related to "gnutls" patch,
and for which if they were to use OpenSSL, there would be a licensing
issue, according to replies to a bug report referenced in the
discussion).

Of course, if Guix project wants to, I can make the set of recipes into
separated patches anyways, with all customizations applied anyways, and
still watch for that discussion. However, due to the amount of patches
and since I don't have confirmation that the patches are being sent to
Ring's upstreams, I would still have to decide between:

a. Taking Ring's patches and registering them formerly at
   "gnu/packages/patches" directory (and related files), and then use
   apply-patch and similar procedures. This would allow better control
   of which patches are applied, but future version upgrades for the
   packages would need testing to see if the patches were applied.

b. Leave the phases that deal with patches as they are. This would allow
   future patches to be picked up as long as the temporary
   "savoir-faire-linux-patches" package definitions are updated
   accordingly, but might also cause future upgrades to not have the
   patches applied (because the custom phases name the patches that are
   wanted).

Personally, I'm more towards choosing (a). But I would like other's
opinions.


Respectfully, Adonay.
-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  Ring, ou Tox. Quer outras formas de contato? Adicione o vCard que está
  no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu aceito,
  mas não repasso. Entrego apenas em formatos favoráveis ao /software/
  livre. Favor entrar em contato em caso de dúvida.
- "People said I should accept the world. Bullshit! I don't accept the
  world."
                                                  --- Richard Stallman

  reply	other threads:[~2017-03-31 19:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-18 23:20 Continuing the work on the recipes related to GNU Ring Adonay Felipe Nogueira
2017-03-19  2:25 ` John Darrington
2017-03-22 19:20 ` Adonay Felipe Nogueira
2017-03-22 19:56   ` Leo Famulari
2017-03-22 20:41     ` Adonay Felipe Nogueira
2017-03-24 23:42   ` Adonay Felipe Nogueira
2017-03-25  0:01     ` Adonay Felipe Nogueira
2017-03-26 13:21       ` Ludovic Courtès
2017-03-31 19:05         ` Adonay Felipe Nogueira [this message]
2017-04-20 13:55 ` Adonay Felipe Nogueira
2017-04-20 15:24   ` Maxim Cournoyer
2017-04-20 16:22     ` Adonay Felipe Nogueira
2017-06-09 19:00     ` Adonay Felipe Nogueira
2017-06-11 20:40       ` Ludovic Courtès
2017-06-30 13:09         ` Adonay Felipe Nogueira
2017-07-30  9:55           ` ng0
2017-07-30 13:16             ` Adonay Felipe Nogueira
2017-07-30 14:45               ` ng0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o9whferw.fsf@openmailbox.org \
    --to=adfeno@openmailbox.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).