From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6656673633724792832 X-Received: by 2002:a50:915d:: with SMTP id f29mr2889352eda.12.1551193214955; Tue, 26 Feb 2019 07:00:14 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:e2ca:: with SMTP id gr10ls3311156ejb.6.gmail; Tue, 26 Feb 2019 07:00:14 -0800 (PST) X-Google-Smtp-Source: AHgI3Iaiy2ficLXqvj/SGJr+YJNJyEISWzZYjbCOzE9sTQHekiatW2Y0dNUjyreFcNhPJ9hqDSq+ X-Received: by 2002:a17:906:d541:: with SMTP id gk1mr2664669ejb.0.1551193214662; Tue, 26 Feb 2019 07:00:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551193214; cv=none; d=google.com; s=arc-20160816; b=Kdx504TjzWimpx3PRP3XgYARp68jj2NPUQrTRJWD2M5APJEd0tFgE80TQxqfOaW65m f00yqrIREngmvdvrUjl2nhgCNGr8vG0omFL0ma9Tl3YatFgol2A2r6VycaTB7w/0ckwc aKsp6rGETV7gfQUVBusMg0Q6tDGLtSQFM+xfH3H+zXHq1G7Tz2lyQfx/3bEDQrHTukz6 o8nMvJuVKGwYJkDLShOYEMdTl+lBvYyS2T1gFT9HNzUWOLL80nu1DrsArluOvxecQGWm cM0OpGmnQTX2Qjs0WwMGWPuZTNX8fsmr14baBEvj8g6K0vP/klwrKWZs/td/yUvRvd6N qEow== 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=P1xFzDbAyskFzrmTsc6QHKIF4gId9IeQJrYoBE2BkL0=; b=Y0m4PetwcNH4hpaECjO6CbXnt7Jq/c1aOr9JSEgDIjVxqikzuR2ZG82n/xsZTnN2rQ n2/13WnrKe6HeTcYmaY2+/16Hzo+Wj4LaLJBNOci8wSYy0OfZnwFq8Yo93NJ9tPfHNME +JuLCvYWdHlqZO05nfLYISwwlRhz8jJ392k0nDe8cgLY88YVtlK5tSa61q8UHBikx5XV dYg6ADnZflo98mJ4moLlyUvwFoy19YfZkRTfCNoJIi7V6hvRSoNA5TvFbHb6hHwmwHcP SWoVMIQdzqe7PMe0d8la4lhuS611cL0w+jZr8lyLZ+09ZuYKAfSnAd47zREmooK33h77 aJ8w== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id a7si318410edb.1.2019.02.26.07.00.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 07:00:14 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x1QF0E8Z002688 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 26 Feb 2019 16:00:14 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.68.253]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x1QF0CQs012688; Tue, 26 Feb 2019 16:00:12 +0100 Date: Tue, 26 Feb 2019 16:00:13 +0100 From: Henning Schild To: Jan Kiszka Cc: Subject: Re: [PATCH] dpkg-base: apt-get "update" before "source" Message-ID: <20190226160013.59c4ad3e@md1za8fc.ad001.siemens.net> In-Reply-To: <0ff54328-5b30-e645-619e-0eaac9c184b5@siemens.com> References: <20190211093324.1444-1-henning.schild@siemens.com> <20190211103526.3d92babf@md1za8fc.ad001.siemens.net> <0ff54328-5b30-e645-619e-0eaac9c184b5@siemens.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: RvCzfLcf93q2 Am Mon, 11 Feb 2019 13:53:07 +0100 schrieb Jan Kiszka : > On 11.02.19 10:35, [ext] Henning Schild wrote: > > Here i see an often repeating pattern. That "apt-get update" is now > > present in many entry points to the buildchroot. > > I guess we should factor it out and put it into a central place. And > > the rule of thumb probably is ... whenever you use anything apt, > > apt-get update before you do ... > > If you are only talking about updating our locally maintained repo > (like below), that is fine to factor out and reuse. However, we must > not update against public repos after the initial pulling, in order > to ensure we have a consistent package set along the whole build. I think that is actually not true. The whole process is an "eventual consistency" topic. Say one of your package compiles for 2 weeks ... you would never be able to build a buster image. And in fact, no matter how long the time windows is. You can always hit the point where a file that should be there according to your view of the repo, can not be downloaded anymore .... in which case you need to "update/upgrade". So i tend to believe that we should always "apt-get update" without restrictions. For people that truly care about having a reproducible build with only one consistent state, they should create images from there partial debian mirror / cache. (where an "apt-get update" is a noop) Henning > Jan > > > > > Henning > > > > Am Mon, 11 Feb 2019 10:33:24 +0100 > > schrieb Henning Schild : > > > >> From: Henning Schild > >> > >> When rebuilding we can run into an inconsistent view where > >> buildchroot assumes it could download the sources of a modified > >> upstream package. After a "reprepro ... remove" we always need to > >> "apt-get update" to not operate on an old version of the metadata. > >> > >> Signed-off-by: Henning Schild > >> --- > >> meta/classes/dpkg-base.bbclass | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/meta/classes/dpkg-base.bbclass > >> b/meta/classes/dpkg-base.bbclass index 175dc80..5425df8 100644 > >> --- a/meta/classes/dpkg-base.bbclass > >> +++ b/meta/classes/dpkg-base.bbclass > >> @@ -31,6 +31,10 @@ do_apt_fetch() { > >> fi > >> dpkg_do_mounts > >> E="${@ bb.utils.export_proxies(d)}" > >> + sudo -E chroot ${BUILDCHROOT_DIR} /usr/bin/apt-get update > >> \ > >> + -o > >> Dir::Etc::sourcelist="sources.list.d/isar-apt.list" \ > >> + -o Dir::Etc::sourceparts="-" \ > >> + -o APT::Get::List-Cleanup="0" > >> sudo -E chroot --userspec=$( id -u ):$( id -g ) > >> ${BUILDCHROOT_DIR} \ sh -c 'cd ${PP} && apt-get -y source > >> ${SRC_APT}' dpkg_undo_mounts > > >