From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 13 Jun 2020 22:32:13 +0300 From: "Vladimir D. Seleznev" To: ALT Linux Team development discussions Message-ID: <20200613193213.GA301853@portlab> References: <20200604195811.3881130-1-vseleznv@altlinux.org> <20200604195811.3881130-2-vseleznv@altlinux.org> <20200605142254.GA4019241@portlab> <20200613174519.GB22306@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200613174519.GB22306@altlinux.org> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel] [PATCH] gb: add gb-task-build-post, optimize packages with identical rebuild X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 19:32:14 -0000 Archived-At: List-Archive: List-Post: On Sat, Jun 13, 2020 at 08:45:19PM +0300, Dmitry V. Levin wrote: > On Sat, Jun 06, 2020 at 04:42:21PM +0300, Alexey Tourbin wrote: > > On Fri, Jun 5, 2020 at 5:23 PM Vladimir D. Seleznev wrote: > > > > > Introduce task post-build processing. It finds subtasks with package > > > > > rebuild and if the rebuilt packages identical to the same packages in > > > > > the target repo it optimizes them. > > > > > > > > It doesn't make much sense. When we rebuild a package without changing > > > > the release, we expect something else in the package to change because > > > > of the rebuild (e.g. a binary will be linked with a new library > > > > version). If the package hasn't changed, it is an alarming condition > > > > which indicates that some of the packager's assumptions were wrong > > > > (e.g. the binary actually doesn't link with the library). So should we > > > > really "optimize" this case? We might as well prohibit it! > > > > > > By "prohibit" you mean make task build fail? I would say that it is > > > unnecessary. It'd produce additional difficulties for maintainers > > > without any profit. > > > > The difficulties are all in the maintainers' heads. > > There must be a valid reason for rebuilding a package. > > Given that rebuilding a package costs so little for the maintainer, > we definitely should reject rebuilds that do not result to changed > packages. So you think than tasks should fail if rebuild do not result to changed packages. I argue with that. Packages optimization in that case is more graceful solution and less disturbing. And imaging the case when you have a big task with a lot of subtasks caused by brand new Python update. Some of these subtasks may be unchanged after rebuild and I don't see why they should be failed. But if they will, this will produce too much needless work for the poor maintainer. Now subtasks do not fail if somebody just rebuilds packages if their builds aren't broken, and if their results unchange packages, we have wasted storage space. If packages will be optimized, this storage space will be saved. But I like the idea to optimize repo updates for optimized subtasks. And I think there will be no harm if task will fail if all of its subtasks will have unchanged packages after rebuild. -- WBR, Vladimir D. Seleznev