From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6659727571892043776 X-Received: by 2002:a1c:e90f:: with SMTP id q15mr1236326wmc.2.1555071003153; Fri, 12 Apr 2019 05:10:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:4e14:: with SMTP id g20ls2954937wmh.1.gmail; Fri, 12 Apr 2019 05:10:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqyZlIjYZTqq29dkOJo2vVBeHbDajcsnpcGD4i4G4O+JqQZQpNO1bVO7RbUjzJaql+QnCnHw X-Received: by 2002:a1c:25c3:: with SMTP id l186mr1076611wml.23.1555071002754; Fri, 12 Apr 2019 05:10:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555071002; cv=none; d=google.com; s=arc-20160816; b=nHykgJU0PMxIGO255tiHaTxRM+D4dBu8S93xY4ukDJILnVvNqGoBtpDsoiAb9MeiEp ya56I3JnL+Ga+lWARJC3Ha+NWgksO82crhJet2l3WRiCN70fi1BZRhEv8bh/py69gBLe /VlaYy3+xX/Ljs2i8z6jQJMcQ/cAJwUcxfzpIGvLSGX9ai/icVV7UVuYqmO5aBLkNjx4 uayuICg2h2u1SocaYGjyGFPxbjYx9O96PkAxES4o0kH2sP4ov+JMlLVY6TyswAhiAi/p y3172oR/TYwxOP55YkDEVopQ8toVncX/Z2uprUCz8WFep4s+H6ZPC1ryKS37qzDfMIr/ nBgg== 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=7GZ4z5+g0Ibu7O13l3/jrZ+6+Z8Sdt5rO2Qd6vRdtyM=; b=qJ92bILOvxKk/tAeOVaSrnprZUWBeltxAQDZRkW9U7HETlTQz9sGjk6gmf7v2u0cEx IOuMPk5bV+qjeNEZJx+RJRotk4nOJ4QjnKI0I62Yd1VIcerYft5QKrlYou/2ynvw0CTM TOQIbIoZu/2suL2maP7jpOZjU1QlscCmKOLohSgVrFxqAq7uGmTkH2vRcEYvbCtq6KYk JqCTHChfYrs/CTYMdmkrmrvYIImZqPr5CKKCXhfOrEt6mjXT2bs6/xd2/wCYmaDa/Rp+ KgdaPa4EaJZA9Z0++K/tzMrMyG7SwtYdXfsZQmgqXQgO3jOu0CYa0M9Ej2OAHvexHlLc fibQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id t14si507620wmj.4.2019.04.12.05.10.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 05:10:02 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x3CCA2ea010435 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Apr 2019 14:10:02 +0200 Received: from md1za8fc.ad001.siemens.net ([139.25.68.211]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x3CCA2QC030989; Fri, 12 Apr 2019 14:10:02 +0200 Date: Fri, 12 Apr 2019 14:10:01 +0200 From: Henning Schild To: Baurzhan Ismagulov Cc: isar-users Subject: Re: [PATCHv3] dpkg-base: derive "Package" and "Architecture" from .deb in cleanup Message-ID: <20190412141001.062bfe7a@md1za8fc.ad001.siemens.net> In-Reply-To: <20190402153104.GW1437@yssyq.m.ilbers.de> References: <20190221155634.20706-1-henning.schild@siemens.com> <20190328110328.GG1437@yssyq.m.ilbers.de> <20190328185056.61434442@md1za8fc.ad001.siemens.net> <20190402153104.GW1437@yssyq.m.ilbers.de> 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: am/NPuMIb6rd Am Tue, 2 Apr 2019 17:31:04 +0200 schrieb Baurzhan Ismagulov : > On Thu, Mar 28, 2019 at 06:50:56PM +0100, Henning Schild wrote: > > > IMHO, it's unclear who is "you" in the commit message. I'd > > > suggest to reword in a more neutral form, e.g.: > ... > > Ok, you or Maxim can fix that on merge. > > Ok, thanks. > > > > I hope it is clear who you is ;). > > Not for some other user reading the commit message later. > > And if you actually address a specific person, I'd ask to avoid that > in the future. We need the description of the problem and of the > solution -- in this patch you got both well. Fingerpointing doesn't > contribute to the project. I think we are still talking about writing style and wording of the commit message. No finger pointing was ever intended or even remotely thought about. I just said "you" to the anonymous reader of the commit message. > > > How can one reproduce the problem? I'd like to understand the > > > cause because at the first glance I'd think an _all.deb package > > > should land in the pool only once. > > > > That is written in the commit message. > > I wanted to ensure I got the context correctly, e.g. 1. whether > isar-apt or base-apt (assuming the former) and 2. local.conf or > multiconfig (assuming the former). We are talking about isar-apt. I did not look into base-apt yet, that was discussed in another thread where i also suggested to inspect the packets with dpkg-deb instead of doing file name guessing. one config or multiconfig does not matter, "all" is no architecture an can not be removed > > > A deployment of "all" will not deploy one .deb of arch "all" but it > > will deploy n .debs of all the archs enabled in the repo. > > So on deploy of "all" from arm into a "arm, arm64, x86" repo you > > will get three copies. The next deploy from x86 will write all > > three again, same for arm64. But they are all the same and just get > > written 3 times. > > Thanks for explaining, this was clear enough from the commit message. > It's the 3 copies that I'd expected to be one. > > > > The easiest way to just get to the "broken" clean is to build an > > "all" package. Deploy it and repo_clean it, you should still see it > > in the other archs ... > > Thanks, I'll try. Did you succeed? > > > That also means we must never use the repo while another arch > > deploys into it because we get sharing over "all". > > My understanding was that we lock reprepro to avoid this. Or am I > missing anything? We lock it for writes and assume that reads will happen after the repo is complete. Because an image depends on all recipes to deploy. In a multiconfig setup a writer (recipe deploy/clean) can remove packages that a reader (image bootstrap) needs. i.e. all arm64 recipes have deployed their debs and arm64 image bootstrap starts, during that bootstrap an x86 recipe deploy removes an "all" deb that the bootstrap needs ... deb missing ... press the jenkins build button again better luck next time Henning > > That is a severe problem if > > you have "all" packages and use multiconf. My suggestion would be to > > avoid both ;). > > "all" is in Debian and we have to handle it. We should also support > local.conf, although I haven't tried it for a long time. > > > > However that issue should be documented or fixed for people who > > care about multiconfig ;). > > I'd look first whether having the 3 copies is correct. > > > > I agree and i am the one constantly asking for tests. All the > > rebuilding patches that got merged so far are not covered by tests. > > I guess some tests that trigger partial rebuilds would be needed. > > But that is probably out of scope of this patch. > > > > Yes we need tests for new features. Tests for corner-case > > bugfixes ... would be handy but holding back bug-fixes for it? > > That was a general wish, also for the mentioned rebuilding patches. > No, missing test case isn't a blocker for me. It would just speed up > testing -- even your temporary manual test case (beyond providing the > longer-term quality, that is). > > > With kind regards, > Baurzhan. >