From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 14 Jun 2020 01:03:26 +0300 From: "Vladimir D. Seleznev" To: ALT Linux Team development discussions Message-ID: <20200613220326.GA355148@portlab> References: <20200604195811.3881130-1-vseleznv@altlinux.org> <20200604195811.3881130-2-vseleznv@altlinux.org> <20200605142254.GA4019241@portlab> <20200613174519.GB22306@altlinux.org> <20200613193213.GA301853@portlab> <20200613210340.GB24260@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200613210340.GB24260@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 22:03:26 -0000 Archived-At: List-Archive: List-Post: On Sun, Jun 14, 2020 at 12:03:40AM +0300, Dmitry V. Levin wrote: > On Sat, Jun 13, 2020 at 10:32:13PM +0300, Vladimir D. Seleznev wrote: > > 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 imagine 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. > > No, I don't buy these arguments. If a subtask produced a non-changer, > just remove it. Ok, that's fine with me, if this remove will be done automatically. But theoretically there can be cases where in non-mixed arches you have non-changed rebuilt packages on some architectures, but changed packages on anoter. I would prefer to optimize non-changed than to pretend that this whole rebuild produced changed packages. Non-mixed arches build means either all the built packages are arch-specific, or they all are noarch. -- WBR, Vladimir D. Seleznev