bug#58149: Letting clients warn about old daemons

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> Hi,
>
> (Cc: Mathieu O. + Maxim.)
>
> Matthieu Haefele <matthieu.haefele@cnrs.fr> skribis:
>
>> I worked intensively with guix this summer, I did not get any
>> deprecation warnings, I am quite sure. And I still do not get any. So
>> might be a good idea to check the deprecation machinery.
>>
>> (base) mhaefele@mdlspc113:~ $ guix shell python-numpy python coreutils
>> (base) mhaefele@mdlspc113:~ $ echo $GUIX_ENVIRONMENT
>> /gnu/store/cy8y10jfnbq5y2r16i13q04h1lii428a-profile
>
> Indeed.  I’ve just realized that commit
> f9c62b23cc88541756656b3ec602ce987828d906, which added that deprecation
> warning, will actually only fire with daemons dating back from before
> 2018 (the date at which ‘PROTOCOL_VERSION’ was last updated in
> ‘worker-protocol.hh’).  Going back to this issue at hand, it won’t
> report a daemon that lacks lzip support.

The commit to the daemon that bumped that protocol is dated Oct 15 2018:
--8<---------------cut here---------------start------------->8---
commit 6ef61cc4c30e94acbd7437f19c893f63a7112267
Author: Ludovic Courtès <ludo@gnu.org>
Date:   Mon Oct 15 22:40:35 2018 +0200

    daemon: Support multiplexed build output.
    
    [...]
    (%protocol-version): Bump to #x163.
    * tests/store.scm ("multiplexed-build-output"): New test.
--8<---------------cut here---------------end--------------->8---

Which would have gotten distributed in a pullable 'guix' with:

--8<---------------cut here---------------start------------->8---
commit 532f92c8f39ef8fa9441bf0840ae642016fac7a5
Author: Ludovic Courtès <ludo@gnu.org>
Date:   Mon Oct 15 23:54:20 2018 +0200

    gnu: guix: Update to f9a8fce.
    
    * gnu/packages/package-management.scm (guix): Update to f9a8fce.
--8<---------------cut here---------------end--------------->8---

That indeed doesn't correspond to the time when lzip was introduced.

> Mathieu, Maxim: I think we need a finer-grain mechanism here, or maybe a
> new builtin that would let a client ask the daemon for supported
> features.

That'd be nice indeed.

Thanks,

-- 
Maxim