Re: [devel] [PATCH] gb: add gb-task-build-post, optimize packages with identical rebuild

["Vladimir D. Seleznev" <vseleznv@altlinux.org>]

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