public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
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

             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