emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ELPA] new package: tramp-docker


From: Philip Kaludercic
Subject: Re: [ELPA] new package: tramp-docker
Date: Sun, 09 Oct 2022 11:54:59 +0000

Richard Stallman <rms@gnu.org> writes:

>   > To my knowledge there is the danger of either having a build-time or a
>   > run-time dependency on a non-free container,
>
> That's what was reported to me.
>
> Does Docker provide an easy way to verify that you have avoided such
> dependencies?  A way to make sure to avoid including them?

As I said, I don't see any such option, but I am not an Docker expert.

>                                                  though looking through a
>   > container index like (https://hub.docker.com/search?q=)
>
> I tried visiting http://hub.docker.com/ and got a blank window.  It depends
> on nonfree software to see even the first page.  We must not refer anyone
> to that site.
>
> Likewise for https://hub.docker.com/search.
>
> I surmise that the standard way to develop a container involves using
> https://hub.docker.com/search.  Is that correct?

Not necessarily, both docker and podman have a "search" subcommand:

        $ podman search gnu
        NAME                                        DESCRIPTION
        docker.io/library/bash                      Bash is the GNU Project's 
Bourne Again SHell
        docker.io/library/gcc                       The GNU Compiler Collection 
is a compiling s...
        docker.io/biocontainers/gnumed-server       
        docker.io/biocontainers/gnumed-common       
        docker.io/biocontainers/gnumed-client       
        docker.io/biocontainers/gnumed-client-de    
        docker.io/matpower/matpower                 A complete MATPOWER 
environment running on G...
        docker.io/matpower/octave                   A complete GNU Octave 
environment, with IPOP...
        docker.io/gnut3ll4/livy-k8s                 
        docker.io/gnubila/mhmd-documentation        
        ...

> Is that the _only_ way to develop a container?  Is it possible,
> practically speaking, to build a container without using that site at all?

It should be possible, first of all because it is possible to configure
what sites to use as an index for images.  But you also don't need to
use the site itself, the "docker"/"podman" commands take care of
fetching everything you need, just like "apt-get" would.

> Has anyone here had practical experience?
>
>                                                            , it appears that
>   > the overwhelming majority of popular software is free software, if only
>   > because distribution is easier.
>
> Alas, that does not by itself ensure that, supposing you build a container,
> you won't consider including nonfree programs.
>
> Is there an easy way you can ensure that _all_ the programs you put
> into a new container are free?  Is there an easy way to verify that
> the contents of a container are free?

Without an index that would only host free software, I don't see how
this would currently be possible.

> After I get a little information here, I will ask on gnu-misc-discuss.
>
>   > That being said, TRAMP+Docker is a popular combination for developing
>   > software, so what people often just do is use a distribution image
>   > (Ubuntu, Debian, Alpine) as the foundation and then instruct the
>   > container to install all the software they need using the distributions
>   > package manager, while building their own image.
>
> I see how that is buzarre, but paradoxically it might work in
> freedom's favor here.  If you use a free distro to build the
> container, and put things in it with apt-get, you will get only free
> software in it.  Maybe that is a reliable method we could recommend.

It also helps people that are stuck on non-free development platforms to
reliably use free software.

Though I should mention, that AFAIK the most popular package manager is
Alpine's "apk", not Debian's "apt-get".

>   > > 3. Distributing free programs in containers tends to be bad for
>   > > the community's control over the program.  Because people
>   > > don't build the program on the GNU/Linux distros they use,
>   > > and don't package it for those distros.
>   > >
>   > > This too we should use the opportunity to warn people about.
>
>   > I think this could be added to the commentary section.
>
> Maybe so, but when you say "the commentary section", could you
> be more precise?  The commentary section of what documentation?

The commentary section (;;; Commentary:) of an Emacs lisp file, as
described in (elisp) Simple Packages.

> After I get a little information here, I will move this to gnu-misc-discuss.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]