[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58149: Letting clients warn about old daemons
From: |
Maxim Cournoyer |
Subject: |
bug#58149: Letting clients warn about old daemons |
Date: |
Mon, 03 Oct 2022 11:12:25 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
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