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

Re: Debian and our frenemies of containers and userland repos



Hi,

shameless plug for mmdebstrap incoming.

Quoting Philipp Kern (2019-10-07 13:21:36)
> On 10/7/2019 1:17 PM, Shengjing Zhu wrote:
> > On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie <smcv@debian.org> wrote:
> >> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
> >>> Specifically, currently autopkgtest is limited to providing a read-only layer
> >>> for certain backends and its upstream has no intention of widening the scope of
> >>> the software [1]. This means that to upgrade an autopkgtest backend, the user
> >>> has to apply backend-specific actions
> >> I think "re-bootstrap, don't upgrade" is an equally good principle
> > Why not have a repository for it, like dockerhub. So this becomes
> > "pull latest build env", which saves lots of time("re-bootstrap" is still
> > slow nowadays).
> In that case it'd probably be better to make bootstrapping faster rather
> than trusting random binaries on the internet. (Unless we grow an
> "assemble an image from debs" service on, say, ftp-master.)

creating a working sbuild chroot takes 10 seconds on my system:

    $ time mmdebstrap --variant=essential unstable debian-unstable.tar
    [...]
    mmdebstrap [...]   8.35s user 1.73s system 99% cpu 10.166 total

Do we need to spend engineering effort to become faster than that?

Downloading "random binary from the internet" is less of a problem if we can
create images which are bit-by-bit identical to checksums that we can verify
through a trusted service. This is also already provided by mmdebstrap:

    $ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential unstable - | sha256sum
    [...]
    f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6  -
    $ SOURCE_DATE_EPOCH=1570448177 mmdebstrap --variant=essential unstable - | sha256sum
    [...]
    f40a3d2e9e168c3ec6270de1be79c522ce9f2381021c25072353bb3b5e1703d6  -

Lastly: yes, maybe "re-bootstrap, don't upgrade" is an equally good principle.
It has the advantage of not accumulating cruft. The sbuild-createchroot command
could gain an option which allows one to replace an existing chroot. Currently,
it refuses to work on already existing chroots.

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: