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?
Thanks!
cheers, josch
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886332#20
signature.asc
Description: signature
