[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debdocker - A Debian docker-based personal builder



On Sat, Jun 27, 2020 at 10:11:20PM +0200, Samo Pogačnik wrote:
> Dne 27.06.2020 (sob) ob 19:43 +0200 je Johannes Schauer napisal(a):

FWIW   I didn't yet get that posting on this mailinglist.


> > 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.
> 
> Hi Johannes,

Hi Mailinglist,


> 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?

Yes, please pursuit that challenge.


Groeten
Geert Stappers
-- 
Silence is hard to parse


Reply to: