Bug#961371: [alexddoyle@gmail.com: Re: debdocker - A Debian docker-based personal builder]
----- Forwarded message from Alex Doyle <alexddoyle@gmail.com> -----
Date: Sun, 28 Jun 2020 08:20:40 -0700
From: Alex Doyle <alexddoyle@gmail.com>
To: Samo Pogačnik <samo_pogacnik@t-2.net>
Cc: stappers@stappers.nl, debian-devel@lists.debian.org
Subject: Re: debdocker - A Debian docker-based personal builder
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.
[ .... previous mailinglist discussion text .... ]
----- End forwarded message -----
And the main reason for updating this ITP BR
is for reporting me as uploading sponsor.
`due` is now on my planning for half July.
Those that have time the next three weeks to beat me on uploading
should surely do. Don't wait for me. (Never wait for me.)
Regards
Geert Stappers
--
Silence is hard to parse
Reply to: