Hi everybody I can field any questions on DUE to save people having to spend time on researching differences - I've summarized some of them for reference below to provide some context about DUE's scope as a build tool, and to assist in comparing potential options. I can see some functional overlap here, but haven't done a deep dive yet. I'd expect I'll be answering questions similar to Samo's - but probably in a different thread as I don't want to hijack the focus of this one.
*TL:DR* - I don't see DUE replacing existing build tools. - Debian packages are an important subset of what DUE can build, but its scope is to make non-Debianized builds easy as well. - I expect its user base would be developers looking for easy deployment of different build environments. - Interesting parallel evolution in the common features of the existing Docker build tools. - Ideally, any software project with a complicated build environment has a DUE template to create that in a container, lowering the bar for project participation. *L* Having quickly looked at debdocker and the other docker based build tools I'm struck by the areas of noticeable functional overlap between all of the tools, indicating that there's an unmet need there. The authors of Debspawn in particular seem to be thinking along the same lines as I am. However, two years ago when I'd started working on what would become DUE I'd had no luck finding build tools that did the sort of things that I was looking for , although as a build tools engineer for a Debian derivative my requirements include a lot of what would be considered edge cases. While DUE makes building packages easy I don't see it replacing the tools that are already used, like sbuild and pbuilder So - what does it bring to the party, then? A number of things, but I'll focus on what, as a developer, I think are the two biggest "value adds" *1 - Convenient Builds, regardless of project (as long as it can build in Debian)* It tries to bring the convenience of building Debian packages - apt get source - install dependencies - build - done! ...to code that isn't Debianized by supporting preconfigured build environments for those programs. - Use it to build the desired container ( pick the Debian version, architecture, and build environment configuration to use via --help ) - check out source, - build source with container (it'll handle the dependencies, etc ) - done! So while Debian packages are an incredibly useful subset of what it can build, they're only one of several (as of now) supported build environments. As an example of non-Debianized code, Open Network Install Environment* ( https://github.com/opencomputeproject/onie) is basically a bootloader for network switches, but currently it just builds in Stretch and has a bunch of build dependencies, and one of them has to be pulled out of GitHub. A template directory in DUE handles all the environmental configuration so everybody working on the project can have identical build environments, regardless of where they are. Anybody curious about the project can try it out with DUE in three steps, and easily toss it if they have no interest. If DUE gets accepted into Debian, I'd hope for a use case where developers for any open source project could provide a DUE compatible template to generate their build environments, and host that along with code so that anybody who wanted to work on their project would apt install DUE, drop the template in, then build the image and be ready to go...but I'm getting ahead of myself here. *2 - Comfortable debug* Trying to debug software from the inside of a typical Docker container is irritating for a number of reasons, but they boil down to: you don't have access to everything you'd like. You're root or some other account. None of your configuration files are around. Files have to be copied in/out of the container to preserve changes if modified: everything is difficult because there's an extra step involved. With DUE any Docker image it creates gets a set of utilities embedded in it, providing convenience (like creating an account in the container that matches the user's on the host system, mounting their home directory for access to config files in addition to source , etc. ) creating a much more comfortable environment for extended debugging/development, etc. I know these sound like small things, and they are...but they get incredibly irritating over time, and having them 'just handled' for any build is _really_ nice. There's more here, but the above pretty much covers the role I think DUE would be playing - and all of that goes beyond the scope of this thread. Thanks! -Alex *Disclosure, I'm the ONIE project lead so I've got the most to gain by lowering the bar for participation. On Sun, Jun 28, 2020 at 3:06 AM Samo Pogačnik <samo_pogac...@t-2.net> wrote: > On Sun, 28 Jun 2020 09:27:09 +0200, Geert Stappers wrote: > > 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> > > > > The ITP for 'due' expresses exactly my sentiments in the Q&A section > question, > if there are other packages providing similar functionality. 'debdocker' is > simply my modest result of that sentiment and i see no harm offering it to > others. > > regards, Samo > >
