<janneke>civodul: i think that would work for me, i assume that these test results are published too and that a second invocation (by someone looking at my substitutes) will just fetch the pre-built result substitute?
<efraim>civodul: I was just going to remove AC_CONFIG_SUBDIRS(src/libffi) from configure.ac
<civodul>janneke: right, the test result is a store item
<civodul>janneke: so we already discussed this? my memory is flaky i think :-)
<civodul>efraim: try to patch 'configure' rather than 'configure.ac', if possible
<janneke>civodul: good. i was wondering about the necessity/feature of being able to install such a result as a package
<davexunit>I'm also a little bit unsure about what the exact feature set of 'guix deploy' should be. if it's just deploying to servers it only covers a fraction of use cases.
<davexunit>it should also support immutable deployments where VMs are never updated, but replaced with new ones.
<davexunit>and then there's the whole "cloud" thing. AWS and OpenStack have declarative infrastructure management tools (CloudFormation and HEAT). people often use wrappers around these APIs in their language of choice to create code that can reproduce their entire production environment.
<davexunit>so I would like 'guix deploy' to be generic and extensible enough to support all of these things.
<davexunit>remote, in-place server updating is just the tip of the iceberg.
<janneke>isnt't that's already pretty useful in itself, and a building block for the rest as well?
<civodul>davexunit: see GUIX_DAEMON_SOCKET in the manual: remote sockets are supported, albeit slowly
<civodul>BTW, i have plans for "guix system reconfigure --remote=host", which is sort of a subset of 'guix deploy'
<civodul>gasp! i wrote an article texlive-2016 where it was typeset in 9pt, and now it's 10pt :-(
<davexunit>in my day-to-day work, my workflow for deploying new software is to create a base ec2 instance, run my build scripts (chef), make an AMI (disk image) of the result, tear down that ec2 instance, create N new ec2 instances with the new disk image, then finally tear down the old ec2 instanecs running old code