bug#27152: deprecation warnings with Guile 2.2.2

[Mark H Weaver <mhw@netris.org>]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> 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.

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