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
