From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6656673633724792832 X-Received: by 2002:adf:e702:: with SMTP id c2mr1341643wrm.31.1551193424785; Tue, 26 Feb 2019 07:03:44 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:6582:: with SMTP id z124ls67284wmb.10.gmail; Tue, 26 Feb 2019 07:03:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IbTLXll5WOs6ECgWQi9Mktg1VbOLs+H39OTmaU0fnn/eaRu21F62adR5qxft6iIQxPpZDkg X-Received: by 2002:a1c:4009:: with SMTP id n9mr361346wma.22.1551193424086; Tue, 26 Feb 2019 07:03:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551193424; cv=none; d=google.com; s=arc-20160816; b=XE5wHdlfqOG4i8SsImBjEPy5X4mmLBzPCiBF75ZZDS7GFi9OgrNzyYmMjt8oXsiR6a 4dwbOfPr9Pe2w8dxn13SiSP/HnzXMigiK9lCNA8OHDByQ4ClPwszPzjLVIjYaLPoaMvX DxguxYqt+XaWOzWU1xgGUMDJzCliR7/jjTh30hppNdsi6vujSeZL7GLoTReytJctt9im o3Dn57RLl5QjRfpbKI/8fHyLyDEDvpBMqI+Y2PffZlgKkpF2GQs/R4P3ZfXKDPQdlY76 PcrZAHo/KSBCYzn1FwlEtURQlnr4619NRbW+Oh5zkdG0iFO6+w1o/B38Xxh4qdwH6EP5 v2oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=mv1T+s/kGuT+/Ls2YbKN3QoMWBS3zML16OXaUiAFSuM=; b=ffu4yW32TSZSONzbCEf0Swmnl2U29LH5XU5mJXkCFa+gYDwuxfu3gAwXn+Ppy3GA3e 0WC5mxdxLKOgjxQi1lb1v6D6aSjOydn5a9KZT3IE9pGFCs62RmhEdjwdK0aNy4ehJvTG MYnynhsB3BnXEdMJycPLrjT433AlfaQJZOYWjfJDGvfNJODxFoAfsZV3JIwftI3spPNM iHGyha5fgeUUarzYuwLMDEd4kmtWsp3Lz6FF2pYSNTb12lttDzbN9WRnNJAolxrPvrBL +6gkvp5lS3sG+hro0ydh4kdm9CU/pSefj37MnpIza5+3aPBYI7mx7BbhxINovuN7snkj k6Hg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id 109si474786wrb.0.2019.02.26.07.03.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 07:03:44 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x1QF3hqZ016927 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 26 Feb 2019 16:03:43 +0100 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x1QF3h1U027972; Tue, 26 Feb 2019 16:03:43 +0100 Subject: Re: [PATCH] dpkg-base: apt-get "update" before "source" To: Henning Schild Cc: isar-users@googlegroups.com References: <20190211093324.1444-1-henning.schild@siemens.com> <20190211103526.3d92babf@md1za8fc.ad001.siemens.net> <0ff54328-5b30-e645-619e-0eaac9c184b5@siemens.com> <20190226160013.59c4ad3e@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: Date: Tue, 26 Feb 2019 16:03:42 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20190226160013.59c4ad3e@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: q17bJ+WUXrQI On 26.02.19 16:00, Henning Schild wrote: > 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 ... Then you will not be able to work. This is no realistic scenario. > 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 Nope, we won't do that - unless we have a stable (versioned and frozen) repo. This does not apply to upstream Debian, so the current pattern is the way to go: single update for a single build. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux