From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7026732926060462080 X-Received: by 2002:a05:600c:4154:: with SMTP id h20mr22819913wmm.189.1636040235172; Thu, 04 Nov 2021 08:37:15 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:fe0b:: with SMTP id n11ls1302662wrr.0.gmail; Thu, 04 Nov 2021 08:37:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWUqdHa0YbKAOQODOhlSkZmYRQWpJlv+iKH4gmpNZPrdi2Z5ior3NBHynF5Aj1PihrgYuV X-Received: by 2002:a05:6000:120a:: with SMTP id e10mr22664031wrx.156.1636040234265; Thu, 04 Nov 2021 08:37:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636040234; cv=none; d=google.com; s=arc-20160816; b=ugj7XEOSXEfyTAkYSuUbONv9UZE1WGkvmmZOwPDwID8cccywotb62fm4whFmNtjfMv 5Zlx5VT/K7yDq/pDZuG3MtauAwqSHquwQ5eU75YGaL4BDkh8pCYmjXFyINfe8VTkbx8s J1oM0TQZj6A0gpVf8NImsJOJ650pCkar6UeLORMk0V9iUoWvid92Mvv+24FvnyIMqHUI soeJ+wI/jBNf28gNKqHbyERjTpr+T3DNdsP2Kg7cmgY6xquD9jOzTvBhOj/Z6QNIgGfW mq4YFUQQMq4Xy3GlFfaXzKH3oTteCvOctDpd+EtlDdrcFdve4sHEJlabXNWWScBe+E5W biFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=DwKXrGR6llTU/fWvCgH7DOp2VXXpN08QwekYPQv8jkw=; b=YBBpcNhJk6IwjMWr1j6/ikkAjyYQmbMR9pu6ICIJMOuCmAxPxjZ2snXep3ezFvpwmS RHmYjxI2V7AyP2P7JfLPjxX2kwAU+JQKy6ZzOmLktbKNzRLN8ypP2AnkNi9RStks7qn9 Wu0XzjI0HVy9zX8gt/oh1aGupdH5AU7N4hGBtXfGgQqAm6ohVsQp3Co9jR+vfZOn+kcd upmh140LGK419ae+JobCyYAVdM3hlDaZVMQW/zK/crySLDbYZOPK8CkmFIH4Z4YXQ0mX +++sHTWhQeLTcdhdvtN1GWV4EG0YSLE4gRwLOMct0/N2L8K/hduhuT1VgDmK0HiAQB// jpgQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id e18si314550wra.2.2021.11.04.08.37.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Nov 2021 08:37:14 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 1A4FbDHm003824 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 4 Nov 2021 16:37:13 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.69.80]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1A4FbDuZ018160; Thu, 4 Nov 2021 16:37:13 +0100 Date: Thu, 4 Nov 2021 16:37:13 +0100 From: Henning Schild To: Jan Kiszka Cc: Subject: Re: RFC: add maximum debootstrap storing time, or check for updates and invalidate Message-ID: <20211104163713.57d5b555@md1za8fc.ad001.siemens.net> In-Reply-To: References: <20211104161227.49668f09@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: XCWBnKohE1UE Am Thu, 4 Nov 2021 16:25:02 +0100 schrieb Jan Kiszka : > On 04.11.21 16:12, Henning Schild wrote: > > 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 > > > > It's all a trade-off: The above will only run when redoing a rootfs, > not when the buildchroot is considered "done" while a dependency > installation later on may still fail. And running such a check on > every rebuild, even when you only want to build a single package, not > a complete image, may take too much time. Right, we will also want that for the buildchroots ... but only after the last package ... not sure how to hook that into the task chain, but can likely be done > I agree that some update check could be valuable, provided its > controllable whether it is executed or not. And bonus for a simpler > way of triggering the invalidation of all bootstrap tasks, faster > than "rm -rf tmp". Yes there needs to be control, on if it is run and if it just warns or actually removes stuff. Not sure when i will get around to doing that. Just wanted to discuss the idea, and do not need to be the one writing the patches. Henning > Jan >