Hi Ludo, On Wed, 21 Oct 2020 17:42:36 +0200 Ludovic Courtès wrote: > zimoun skribis: > > > The tool is 'skopeo' and packaged in Guix. > > > > However, push to DockerHub requires an account (by Guix project) which > > requires... probably non-free JS, at least once. > > Hmm OK. Users of Docker wouldn’t have to create an account and run the > non-free JS, so this is probably acceptable. > > The next problem is: what would this image contain? ‘guix pack guix’ is > probably not enough because people expect the daemon to be running. > Adding ‘--entry-point=bin/guix-daemon’ probably isn’t good either > because ‘guix-daemon’ never exits, which I think is contrary to what > users expect. It really depends on how people use the images. It's totally normal for docker containers to start services they need in the foreground on container startup, and people then entering that running container from the outside anyway (!) using docker tools. The guix I packaged on https://gitlab.com/daym/guix-on-docker/ is specifically used as a test runner, which is why I background guix-daemon there. Otherwise, the gitlab test runners would hang waiting for guix-daemon to finish (which never happens). If I wouldn't need that, I'd totally not background stuff. > For the same reason, an image produced by ‘guix system docker-image’ may > not be OK because ‘shepherd’ never returns. > > Should we change ‘guix system docker-image’ such that ‘shepherd’ is > started in the background? Why? Docker tools are perfectly capable of entering a docker container where a foreground process is running. Also, one has to be careful that the container doesn't get stopped since the last process finished.