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

Alexey Tourbin alexey.tourbin на gmail.com
Сб Июн 6 16:42:21 MSK 2020


On Fri, Jun 5, 2020 at 5:23 PM Vladimir D. Seleznev
<vseleznv на altlinux.org> 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.

> > The packager should be cognizant that some of his efforts aren't
> > making any difference. :)
>
> But packager can know that this kind of effort aren't making any
> difference because of build log warning. And this can be convenient in
> case of mass rebuild, for example.

So are we to permit the tasks that don't change the repo? Then you
should also optimize base/pkglist and the and release files, their
timestamps should not be clobbered. So that the end user immediately
sees there's no need to update from the repo, although a few tasks
have been committed.  Nice optimization this, eh?


Подробная информация о списке рассылки Devel