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.