Web lists-archives.com

Re: Announce: docker-buildpackage

Quoting Ian Jackson (2018-05-01 16:38:28)
> Geert Stappers writes ("Re: Announce: docker-buildpackage"):
> > On Tue, May 01, 2018 at 09:41:13PM +0800, Paul Wise wrote:
> > > On Tue, May 1, 2018 at 9:23 PM, Enrico Weigelt, metux IT consult wrote:
> > > > I've written a tool for isolated deb builds in docker containers.
> > > > It's a little bit like pbuilder, but using docker for isolation.
> > > >
> > > > https://github.com/metux/docker-buildpackage
> > > 
> > > Does it have any advantages over whalebuilder?
> > 
> > https://tracker.debian.org/pkg/whalebuilder
> > 
> > Homepage: https://www.uhoreg.ca/programming/debian/whalebuilder
> > Debconf talk: https://debconf17.debconf.org/talks/84/
> Do either of these things provide an autopkgtest virt server ?
> That's an executable you can run and speak a protocol to do virty
> kinds of things.
> sbuild and autopkgtest can use any virt system provided in that form.

Unfortunately, according to Martin [1] it is out of scope for autopkgtest to
also add support for making persistent changes to the underlying backend. This
in turn means, that an operation like:

    $ sbuild-update -udcar unstable

will never work for the autopkgtest backend.

I still think that it's a better idea to add another autopkgtest backend than
to write yet another sbuild/pbuilder-like tool. But for the autopkgtest backend
to really take off as an sbuild backend, maybe it would be possible to write a
tool that provides a common interface to make persistent changes to autopkgtest
backends? I don't know if it's possible for a third party application to plug
into autopkgtest and offer such functionality as part of its API?


cheers, josch

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886332#20

Attachment: signature.asc
Description: signature