From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6834022395126218752 X-Received: by 2002:a05:600c:28c1:: with SMTP id h1mr4446425wmd.174.1598253483047; Mon, 24 Aug 2020 00:18:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:287:: with SMTP id 7ls2127566wmk.3.gmail; Mon, 24 Aug 2020 00:18:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWFqMQJmwfGwsmQ4+NQpZaLjX2HzOeaws5o2RniWyzuExj4aGhvKTlNOECkYB4FXeFU3qg X-Received: by 2002:a7b:c95a:: with SMTP id i26mr4546773wml.106.1598253482253; Mon, 24 Aug 2020 00:18:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598253482; cv=none; d=google.com; s=arc-20160816; b=QjT4VXAEsyCS/cjklklf6GWCU8ZuRsOrpjTIsoMDGlZCMP7lyWpmXSN5H41iUYHB8A 1hd9R9BKJbZiCnrnD47qk6mLGQySyNnmhcvzW0LUcA7ZoW7PtLyYI3RAp/qi/VMS9TTZ vlutqeF69EBbrHHL3nnTgUmVCj60ASdkD1QD3w001XaxODjgmDbruD5NIuymK4l289PP uM0iulPzl1JzsUEKgi2H4KoHg9f6hscBUcY06Q4/pHA2gWksgGrY1z0WKT8kDzOq7A/E FYGolLx9tmc2tw1KwS4Wk4mo2Tr173ZjIe/4Ihl2bJo38AdNxwTs6mY7qtJhTn+787AG siVg== 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:to:subject; bh=2BQW1rT/72XcNN5jXPoAqmslSVyR+UVCUn0B5NPkNfA=; b=n84g0Rp4/0BmjBTECPy+Ws+NUqOfHdOBJ/0HBj2Ieei6qPH6AYw5kg2ACOdt45actQ AIr0gMROcNPe+c1gwY29JQEjM0JDX1ubw6Zi71ocdioKkPLNB/u6vru+zpjkDjRYX6YW 3CRCk3w9Q23tLPGa4p6zc8IEBfgZ7EXfgcgXWBA7wluY7aICaksGg4ge+jvgIeNr7eoD N5jQKwyraO5tG9JP2WYY3Ew4dDZ8OYp9tIZdQvgqrNZ3BONmSLRtl6Cyw7Ry526gctHv Ojoi6WKRmRnFsCSbBcqSF9wEaur5VvtpQsX7Xh5Dqhd0YRTaDTXv+7h+33gRC7SdIv+a pVZA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id y12si250793wmc.1.2020.08.24.00.18.02 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Aug 2020 00:18:02 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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 07O7I11Q029510 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 24 Aug 2020 09:18:01 +0200 Received: from [167.87.131.75] ([167.87.131.75]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 07O7HxRh031626 for ; Mon, 24 Aug 2020 09:18:01 +0200 Subject: Re: [PATCH v2] dpkg-base: Remove newly deployed debs from buildchroots To: isar-users References: <20200817192751.GK12511@yssyq.m.ilbers.de> <392163c4-00a2-3462-0f3e-dda06c22a656@siemens.com> <20200823163037.GC11779@yssyq.m.ilbers.de> From: Jan Kiszka Message-ID: <053e7542-5ef5-d86f-5615-bee81ad0d87d@siemens.com> Date: Mon, 24 Aug 2020 09:17:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200823163037.GC11779@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: yn8+l/ejPLeG On 23.08.20 18:30, Baurzhan Ismagulov wrote: > On Tue, Aug 18, 2020 at 07:57:26AM +0200, Jan Kiszka wrote: >>> Yes, Debian Policy section 3.2 requires that different packages have different >>> version numbers. Maybe we should introduce a script that would do that for the >>> developer. >> >> This won't help in the cases you play with a recipe, change small >> details, rebuild, test. It's reasonable to update the version when >> publishing. However, it's a needless burden to do that for a local >> development cycle. Here, Isar shall support that the just built instance >> of a package is also used locally, without an explicit "clean". > > If this is how the upstream tooling works (which is a requirement for them > since there is no other way), things will get complicated and keep breaking. An Can you name concrete other issues? > alternative could be to automate version bumping by requiring a local commit. > In the long term, I don't see a way around that. Commits for rebuilds are user-unfriendly. We will need to solve that in a better way versioning should actually require a bump. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux