On Sun, Jun 28, 2020 at 08:29:22AM +0300, Tzafrir Cohen wrote: > On 27/06/2020 14:52, Mo Zhou wrote: > > Hi Samo, > > > > I'm insterested in its differences compared to the following existing > > docker-based builders: > > > > 1. debocker https://people.debian.org/~tomasz/debocker.html > > 2. whalebuilder https://www.uhoreg.ca/programming/debian/whalebuilder > > > > And there is a systemd-nspawn-based builder too: > > 3. debspawn https://github.com/lkorigin/debspawn > > There is also the recent ITP of due: > https://bugs.debian.org/961371 > that is a docker builder (Debian packages, or more generic) >
Qouting that Intent To Package, ITP: <qoute> * Package name : due Programming Lang: Bash Description : Wrapper tool to create and run Docker container software build environments. Dedicated User Environment (DUE) is a framework for creating preconfigured build/development environments in Docker containers. It serves two primary purposes: 1 - Maintains configurations for creating Docker images for any build environment, using any architecture of any Debian based release it can find an image for. For example, the Open Network Install Environment (https://github.com/opencomputeproject/onie) currently builds on Debian 8 and 9, but requires some Backports packages, and a program that isn't packaged for Debian. DUE maintains a configuration to get all of that added when the Docker image is created so ONIE can 'just build'. Apart from not requiring the end user to have to configure the build environment, it also allows all developers to use the same build environment when debugging - regardless of where they happen to be. 2 - It goes beyond 'just using a Dockerfile' by using a launcher application that supplies runtime configuration to Docker for the Docker images it has created. Apart from reducing typing and being smart about the containers that it runs (ex: containers building Debian packages mount the host directory _above_ the build directory so the resulting .debs aren't stored in the container), DUE preserves the user's identity in the container by creating an account for them with their user ID, and mounting their home directory so they can access their .config files. This creates a less intrusive development environment when the user is in a build/test/debug cycle. While the above are the most important features DUE provides, there are a lot more ways it makes using different development configurations easier, which are documented in the Readme.md (https://github.com/CumulusNetworks/DUE/blob/master/README.md) </qoute> Regards Geert Stappers -- Silence is hard to parse
