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.
