Bug#961371: ITP: due -- Wrapper tool to create and run Docker container software build environments.
Owner: adoyle <firstname.lastname@example.org>
* Package name : due
Version : 1.3.1
Upstream Author : Alex Doyle <email@example.com>
* URL : https://github.com/CumulusNetworks/DUE
* License : MIT
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
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)
I also created a tutorial video using DUE to build ONIE as part of a talk I gave at
OpenCompute here: https://www.youtube.com/watch?v=-5onRbZA0QQ&feature=youtu.be
DUE came out of work I did at Cumulus Networks to provide build environments for
teams of engineers building packages for Cumulus' Jessie and Buster based
releases of Cumulus Linux. When I took over as ONIE Project Lead, I saw the opportunity
to use it to create a standard way of setting up build environments for ONIE and any other
software projects. Cumulus saw the value in any developer being able to use it
and DUE was open sourced under the MIT license.
Why is this package useful/relevant?
Is it a dependency for another package?
No. It does require a version ( Debian or upstream ) of Docker to work though.
Do you use it?
All. The. Time. Building packages at work, building ONIE, and if I just need
an environment to quickly test configuration changes.
This 'dogfooding' has provided insight into fixing program behaviors that
initially seemed okay, and then became irritating through repeated use.
If there are other packages providing similar functionality, how does it compare?
I looked around for quite a while before starting on DUE ( why reinvent the wheel?),
but couldn't find anything that had the combination of:
- Consistent, user friendly interface
- Easy build environment configuration
- And support for Debian derivatives
...that I was looking for.
I think the closest software to this would be using schroots, and while they
can be functionally the same, the end user experience, especially for users that
are new to Debian ( or are trying to build code that partially exists outside
the Debian ecosystem ) has less of a learning curve, and is faster to set up.
How do you plan to maintain it?
I will be updating the upstream source and doing the work to make sure it is
Are you looking for co-maintainers?
Not at the moment.
Do you need a sponsor?
Yes, as I am not a Debian Developer ( in the official sense, anyway :) )
Thank you for your consideration,