From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6659727571892043776 X-Received: by 2002:a1c:a8cc:: with SMTP id r195mr90077wme.20.1553795457940; Thu, 28 Mar 2019 10:50:57 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:db08:: with SMTP id s8ls243031wri.16.gmail; Thu, 28 Mar 2019 10:50:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqy/xJ/1w94fQa5VT55SSjBXt/AXNYLoMzk3zlvRrgbaug5xUVCW1UXh44AUIezac+Z8K2ku X-Received: by 2002:adf:9c8f:: with SMTP id d15mr686096wre.15.1553795457540; Thu, 28 Mar 2019 10:50:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553795457; cv=none; d=google.com; s=arc-20160816; b=05EN/KOTvGayNeqOxZRmz3NurXwbSEonSI3k4RV+Tu/1K8wLCjA46ey35Iy6FUwECI XJUYrYBijXzihCssLhfaGrPyltDlRoQ0qia30LsBffI3MZCjJekTA+/OeM2IUGpztGWH /TY2Ejq+wMWpcdvCOV1IFAlLdwkPRDZZWWCw7SmtxFvetd6FPIgHRxb7glfKpzDJ8DIL fEbPKv9fEzs+Bqecc9m0nWbujMgqYk5IS7dgtaR6k39vGubQ9q1WXtKamFwdpIaXPLEA R49sBDRf7iatLBTJfivhj+qJF4CXBKENLai4R+hBalYwoGl6deR2KI/cVKjAsjsuYKVm k+6w== 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=c9aHrX9F1TkYLt+kVGI/i/nHRR0EhwscsG+gbDy6WN4=; b=Bb4Dhcmi/EzMslVawxg/iH8F6tDH0RIQC3CUFrrZPhfNXdZGXp9py8oObrB1WkYEB9 KWTbpRqe4Oe6SWbMB3iCZfQ5Tz6Ne5Go7Al8S9H5AJFGUYMQG5ggJUzwmuqYSjdfmNga u7IZTA/otDB+QotsNZ1tZgrECJrM4cqKEIY2jfkbVADq+FJ+Iom+S3l725yFz0RUwgqc 8cfaNdJhcifKGStss5WAthkAeBclQHP7FUiyRQVfytW7Y9dO96p9AWn8iqkjg5P0eigZ dRcnXWd50MBYH6gEwQ1A+YvRqh8RP3pgmfFQbWCfzCcd/VFjl3NaGrdmk/86yCZkKjN/ a5HA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id n65si153145wma.1.2019.03.28.10.50.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 10:50:57 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x2SHovgh026191 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Mar 2019 18:50:57 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.0.45]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x2SHou0a022241; Thu, 28 Mar 2019 18:50:56 +0100 Date: Thu, 28 Mar 2019 18:50:56 +0100 From: Henning Schild To: Baurzhan Ismagulov Cc: isar-users Subject: Re: [PATCHv3] dpkg-base: derive "Package" and "Architecture" from .deb in cleanup Message-ID: <20190328185056.61434442@md1za8fc.ad001.siemens.net> In-Reply-To: <20190328110328.GG1437@yssyq.m.ilbers.de> References: <20190221155634.20706-1-henning.schild@siemens.com> <20190328110328.GG1437@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: L1CPig3+JmAW Am Thu, 28 Mar 2019 12:03:28 +0100 schrieb Baurzhan Ismagulov : > Hello Henning, > > On Thu, Feb 21, 2019 at 04:56:34PM +0100, Henning Schild wrote: > > If > > your recipe created such a package it could never be cleaned > > because it was added to all the archs of the repo, and later > > cleaned only from one. Now if that package changes because you are > > still working on the recipe, adding the package again would cause > > checksum mismatches for all but the current architecture. > > IMHO, it's unclear who is "you" in the commit message. I'd suggest to > reword in a more neutral form, e.g.: > > -your recipe created such a package it could never be cleaned because > it +a recipe created such a package it could never be cleaned because > it ... > -Now if that package changes because you are still working on the > recipe, +Now if that package changes because one is still working on > the recipe, > Ok, you or Maxim can fix that on merge. I hope it is clear who you is ;). I will be out of office for two weeks, if you dont the patch will have to keep waiting. > > + p=$( dpkg-deb --show --showformat '${Package}' ${d} ) > > + a=$( dpkg-deb --show --showformat '${Architecture}' > > ${d} ) > > Thanks, this is better than sed. > > > > + reprepro -b ${REPO_ISAR_DIR}/${DISTRO} \ > > + --dbdir ${REPO_ISAR_DB_DIR}/${DISTRO} \ > > + -C main ${aarg} \ > > + remove ${DEBDISTRONAME} \ > > + ${p} > > 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. 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. But a clean of "-A all" is a no-op since that arch does not exist. That clean will not actually clean up the deployment correctly. And subsequent changes deploys will run into problems. 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 ... If you still need to see more change anything in the recipe keeping all of ${P} the same, the deploy should fail. That also means we must never use the repo while another arch deploys into it because we get sharing over "all". That is a severe problem if you have "all" packages and use multiconf. My suggestion would be to avoid both ;). However that issue should be documented or fixed for people who care about multiconfig ;). > In general, subtle stuff like this should ideally be covered with a > test case. 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? Henning > > With kind regards, > Baurzhan. >