Re: isar-bootstrap

[ydirson@free.fr]

> For the download Isar goes the pragmatic way and lets debian fetch
> what
> it wants. With a few exceptions ... i.e. there is only one "global
> apt-get update" so you have to hope that you can apt-get install what
> that initial run created your external database for. In practice that
> does not fail too ofter ... or you have to clean build again.
> 
> If you really need to pin debian down to what it fetches, because for
> some reason (like repro build) you need your own mirror. In fact Isar
> spits out a partial debian mirror after an "online" build (base-apt).
> That can be used for consecutive offline builds, or as a base for
> consecutive "online" builds with custom DISTRO_APT_SOURCES.
> 
> While snapshots.debian.org can be used as DISTRO_APT_SOURCES mirror
> in
> theory ... in practice it has rate-limiting in place. So you might
> succeed in a manual build that you retry over and over (or a small
> image), but in CI without caching ... you will never get a big image
> to
> build. That rate-limiting issue will need to be discussed with
> snapshots, we are not the first ones to have issues with it.
> But i personally would tell people to simply not freeze if they can,
> and the ones that need to freeze i would in fact tell to get a full
> debian mirror of their own, instead of a partial one produced by
> isars
> base-apt.
> As an OSS project you might see less of a need of freezing, tracking
> in
> fact is a security feature ... and debian will not do much more than
> security on their stable distros.

This is more of a concern for reproducibility of the build process
at package level.  Probably this was not published very widely, but
there has been work on Debian package reproducibility in the context of
Qubes already, including a solution to the snapshots.d.o problem:

https://forum.qubes-os.org/t/reproducible-builds-for-debian-a-big-step-forward/6800

Best regards,
-- 
Yann