From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#27152: deprecation warnings with Guile 2.2.2 Date: Sun, 04 Jun 2017 18:04:30 -0400 Message-ID: <87h8zvv28h.fsf@netris.org> References: <87wp8y2ijw.fsf@elephly.net> <87h90091y4.fsf@gnu.org> <871sr1yiik.fsf@netris.org> <87h8zxr89y.fsf@gmail.com> <871sr0wcto.fsf@netris.org> <878tl8pag3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHddx-0007h2-TN for bug-guix@gnu.org; Sun, 04 Jun 2017 18:05:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHddu-0008RO-N9 for bug-guix@gnu.org; Sun, 04 Jun 2017 18:05:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:53540) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dHddu-0008Qo-KC for bug-guix@gnu.org; Sun, 04 Jun 2017 18:05:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dHddu-00041U-8I for bug-guix@gnu.org; Sun, 04 Jun 2017 18:05:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <878tl8pag3.fsf@gmail.com> (Maxim Cournoyer's message of "Sat, 03 Jun 2017 22:51:24 -0700") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Maxim Cournoyer Cc: 27152@debbugs.gnu.org Maxim Cournoyer writes: > Mark H Weaver writes: > >> Maxim Cournoyer writes: >> >>> Mark H Weaver writes: >>> >>>> Maxim Cournoyer 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. It's true that security conscious users would still have the option of building Guix, Guile, GnuTLS, and maybe some other prerequisites from source code, but that's a lot of work to try Guix for the first time. The other option currently available to them is to install a 'guix' package from their distro, but I guess that most of those distro packages would have to be dropped (or not upgraded anytime soon) if we stop supporting guile-2.0. Having said all of this, I acknowledge that it's not a strong argument, and if it starts becoming difficult to support guile-2.0, then we should drop that support. I don't feel strongly about it. > Thanks again for sharing your thoughts, Likewise, thanks for the discussion! Mark