Re: Releasing guix binary in Docker format too?

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Hi Ludo,

On Wed, 21 Oct 2020 17:42:36 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> zimoun <zimon.toutoune@gmail.com> 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]