Hi, Ludovic Courtès <ludovic.cour...@inria.fr> writes:
> Hi, > > (Cc: Mathieu O. + Maxim.) > > Matthieu Haefele <matthieu.haef...@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 <l...@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 <l...@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