From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6659727571892043776 X-Received: by 2002:ac2:51d0:: with SMTP id u16mr2053891lfm.2.1554219067943; Tue, 02 Apr 2019 08:31:07 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:9a8b:: with SMTP id p11ls1732357lji.11.gmail; Tue, 02 Apr 2019 08:31:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqxeIkOph84/Q5kSXY8sSo+c0l8qZwnw0kAA7MdT9fM95W7S/+GftiA4OZ/nFUe6Uv1OMECH X-Received: by 2002:a2e:85d3:: with SMTP id h19mr2382088ljj.22.1554219067343; Tue, 02 Apr 2019 08:31:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554219067; cv=none; d=google.com; s=arc-20160816; b=TVGCPKql7OyZM1nUnFma6uAjVc38/b8jEWxF7QGoqA6sfRKsnR55ElkuDUOFpGzLCu Yntcj5bWm1cd7SCcjndStU2oWvsL4L2BUWVcYWV9hvIhssw4g/A/MgAd7ImoHATPAkQ7 S0q7c6Did21dRyliGqHVKciY2A6ukRVETQL30CYfTvahOPmhalZ+zajMdRAHmRnDhi4E Rhfj9hPyZycwCKwCHArItQpmzUDzK8QQZqZSANW6ZKUmhL3irWzpulnl0e4ZuGR7Ec6e aWdlXJbzkXzYuHEtHkzVAJ0oPejuVCDTPQ7af3ff6FzvNbgjOcvn6YdSUqs8OjAGvXQp CrXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=1byeSE4d8AsxsYGtlOzmBn8YJZ6VITcWWXpSOn+Yxik=; b=AeA6OiUoAisxTMg6sizw+MFx01js4Jqc4lYa1/8AZE35FGLV/FpMI0mQA5BiL/jwte f/ijQjWV/WBqTM7torNni4AQhhDNTvv8wYlaAQd2qwUKR4Fg4kMT4wNRXTzBOeV2gL53 chdBvcGnaDW386/EjdIQljR0nV3pTCeOmR3ZBXTtrNNFZxcaFoyYQcBu45PPWlC0fV/m bS/aN80GYkscQfHtOPY0CP398DEFwKHeOXMMPUDAJZbTwD06OVSK3MEvnPtWBzSO6r5I pki392RBIIE7Rl0bvwOYjvtCBBbWhL2kn6OQvPyH2iKaazM/8a2BufEyDNVigRmIYc4f Ca4A== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id h21si618988lfm.4.2019.04.02.08.31.07 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 08:31:07 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x32FV4Ds002822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 2 Apr 2019 17:31:06 +0200 Date: Tue, 2 Apr 2019 17:31:04 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCHv3] dpkg-base: derive "Package" and "Architecture" from .deb in cleanup Message-ID: <20190402153104.GW1437@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <20190221155634.20706-1-henning.schild@siemens.com> <20190328110328.GG1437@yssyq.m.ilbers.de> <20190328185056.61434442@md1za8fc.ad001.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190328185056.61434442@md1za8fc.ad001.siemens.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: XnyJ7qqcygvV 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. > > 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). > 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. > 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? > 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.