Re: debdocker - A Debian docker-based personal builder
Hi Johannes,
thank you for all your comments and for pointing out the efforts with 'sbuild'.
I agree with everything you said, however imho it is not always the whole truth.
For example most of our beloved OS is a result of yet another sw for someone's
need. There is almost no SW segment that would not provide at least two
implementations of almost the same thing. In my case i spent quite some time
looking for a container based builder and checking, if the main builders
'pbuilder' and 'sbuild' could use containers instead of chroot - unsuccessfully.
After too much time "wasted", i end up writing 'debdocker', which anyone could
use (hence these posts). I would suggest you also try it as a sandbox for a
simple/sample docker usage.
Regarding 'sbuild' docker backend, i would gladly try to help, however i would
probably need some guidance. After a quick look at #867176, there is an 'sbuild'
patch available, but you are also talking about 'autopkgtest'. What exactly
needs to be done regarding the patch?
regards, Samo
Dne 27.06.2020 (sob) ob 19:43 +0200 je Johannes Schauer napisal(a):
> Quoting Samo Pogačnik (2020-06-27 19:01:57)
> > Dne 27.06.2020 (sob) ob 13:44 +0200 je Philipp Hahn napisal(a):
> > > I think there also was a discussion to include Docker support into
> > > sbuild, which would allow autopkgtest to use that interface.
>
> Yes, this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867176
>
> > > <https://wiki.debian.org/SystemBuildTools> also list several other tools
> > >
> > > So please clarify why we need yet another tool and what are the benefits
> > > of your tool compared to the other ones already existing. Not only for
> > > us Debian Developers, but also in the package description for all other
> > > users looking for the right solution for their problem. Thanks.
> >
> > I can not really say what are the benefits of my tool since i do not know
> > other tools well.
>
> I think before starting to write any software, you should do exactly that:
> perform a review of what already exists, so that you can point out which
> problem your software is solving that existing software is not capable of.
> Otherwise, it's easy to fall into the NIH trap. And maybe there already exists
> some software which does 90% of what you want to do so that you don't even
> have
> to spend much work anymore.
>
> > It is good to have more tools available, at least until all use-
> > cases float out and get covered by the ultimate tool or a set of tools.
>
> Maybe, but that's not what is happening. Including your tool we now have
> *five*
> different "build packages with docker" applications. But with sbuild and
> pbuilder we already have had tried and battle tested tools for package
> building
> for *decades* and we already know which interface we need. Those tools just
> need to have the additional backend. But instead of somebody maintaining a
> docker backend for an existing packaging tool, we now have the fifth iteration
> of somebody writing yet another interface for something that already has had
> an
> interface for decades.
>
> I cannot apply the sbuild patch for docker support in #867176 for docker
> support myself because I never used docker in my life. But sbuild is team
> maintained and whoever wants a "build packages inside docker" tool can simply
> join the team and maintain the sbuild docker backend there. Or maybe even add
> a
> docker backend to autopkgtest so that "use docker for X" can even be added to
> more stuff automatically because autopkgtest provides a unified interfaces to
> many virtualization backends.
>
> I cannot tell any volunteer what to do with their free time but as you
> probably
> can see I'm quite a bit frustrated how much work is put into writing yet
> another (now the fifth) iteration of "build packages inside a docker
> container"
> without somebody leaving the NIH bubble and adding docker support to existing
> tools like sbuild, pbuilder or autopkgtest...
>
> Sorry for the rant. I know that it's not helping my cause.
Reply to: