unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: 27152@debbugs.gnu.org
Subject: bug#27152: deprecation warnings with Guile 2.2.2
Date: Sat, 03 Jun 2017 22:51:24 -0700	[thread overview]
Message-ID: <878tl8pag3.fsf@gmail.com> (raw)
In-Reply-To: <871sr0wcto.fsf@netris.org> (Mark H. Weaver's message of "Sun, 04 Jun 2017 01:18:11 -0400")

Hello Mark,

Mark H Weaver <mhw@netris.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>>
>>>> Why not let good old sed have a run at it? Seems like a simple find
>>>> and replace operation, and 'block looks nicer than _IOFBF to my
>>>> eyes.
>>>
>>> If we did that, then Guix would stop working with guile-2.0.  Given that
>>> guile-2.2 is not yet available from many popular distros, I think it
>>> would be unwise to drop guile-2.0 at this time.
>>
>> Isn't Guile included in the Guix binary releases?
>
> Yes, but that's not the only supported method to install Guix.  While I
> acknowledge that most new users are happy to use our binary tarball,
> many users prefer to compile our source tarball, or to try out a Guix
> package provided by their existing distribution.
>
> Security conscious users tend to be nervous about entrusting their
> computer's security to a source of precompiled binaries that is new to
> them.
>
> While it's true that they will need our bootstrap binaries, and that
> they are highly likely to end up using our binary substitutes before
> long, it nonetheless seems to me that it is best not to ask newcomers to
> trust a large binary from us as their first step into our community,
> without providing other easy methods that are more comfortable to them.
> Users are comfortable installing a package from a distro that they've
> already put their trust in.
>
> So, I would prefer to continue supporting guile-2.0 until guile-2.2 is
> more widely deployed in popular distros, or at least until it becomes a
> hassle to continue supporting guile-2.0.
>
> I'll also mention that there's apparently an unresolved bug somewhere
> (guile2.2-ssh?) that prevents us from using guix-based-on-guile-2.2 on
> hydra.gnu.org:
>
>   https://bugs.gnu.org/26976
>
>        Mark

OK, I understand better your point of view now, thanks for taking the
time to explain it in details! I'd be somewhat concerned though about
Guix sooner than later not running smoothly on Guile 2.0 due to the vast
majority of users using and testing with Guile 2.2 rather than Guile
2.0. There was some breaking changes in 2.2, and it seems like wanting to
support both might lead to code complexity or restraint that would
otherwise allow simplifications and clean-ups of the code base.

Also, nothing is stopping security minded individuals from building
Guile 2.2 from sources, so the argument about security seems a bit moot
to me.

But I will leave it to the Guix maintainers to decide what works best
for minimizing their load :)

Thanks again for sharing your thoughts,

Maxim

  reply	other threads:[~2017-06-04  5:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-30 20:31 bug#27152: deprecation warnings with Guile 2.2.2 Ricardo Wurmus
2017-05-31 21:00 ` Ludovic Courtès
2017-06-03  0:39   ` Maxim Cournoyer
2017-06-03  1:20     ` Mark H Weaver
2017-06-03  4:43       ` Maxim Cournoyer
2017-06-04  5:18         ` Mark H Weaver
2017-06-04  5:51           ` Maxim Cournoyer [this message]
2017-06-04 22:04             ` Mark H Weaver

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=878tl8pag3.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=27152@debbugs.gnu.org \
    --cc=mhw@netris.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).