On Sat, 13 Jun 2020 20:45:19 +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.

There are valid cases when it is impossible to determine beforehand
if rebuild will result in changed package or not, e.g. during boost
updates.

Best regards,
Andrew Savchenko