From: Henning Schild <henning.schild@siemens.com>
To: <isar-users@googlegroups.com>
Subject: RFC: add maximum debootstrap storing time, or check for updates and invalidate
Date: Thu, 4 Nov 2021 16:12:27 +0100 [thread overview]
Message-ID: <20211104161227.49668f09@md1za8fc.ad001.siemens.net> (raw)
Hi,
Isar does have the problem that a debootstrap does the only real
"apt-get update". That is in fact intentional but can lead to the
situation where an outdated chrootfs can break a build. I.e. apt-get
wants to install a package in a version that is not available upstream
anymore.
Now when this happens is impossible to say. It depends on the amount of
packages one has, maybe the distro one is using (sid moving faster than
oldstable), and frozen custom mirror never moving.
With local builds people usually clean all, and for sstate people will
also have to find their own way of dealing with it. But one could say
... it is becoming more of a problem. Not something to not merge the
sstate changes for, but something to think about for the future.
My current idea would be to introduce
DISTRO_MAX_CHROOT_AGE?="3d"
anon python function
if /var/..apt/ older than DISTRO_MAX_AGE
cleanall bootstrap recipe, or somehow enforce re-run
An alternative (maybe better) would be to say
check_for_updates after rootfs_install
copy rootfs to rootfs_tmp
chroot rootfs_tmp
apt-get update
if "apt-get upgrade is not empty"
bbwarn(image lacking some updates that meanwhile have been
published)
cleanall bootstrap recipe
if ISAR_BE_STRICT_ABOUT_THAT=true
fail
Henning
next reply other threads:[~2021-11-04 15:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 15:12 Henning Schild [this message]
2021-11-04 15:25 ` Jan Kiszka
2021-11-04 15:37 ` Henning Schild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211104161227.49668f09@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox