ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Andrey Savchenko <bircoph@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] [PATCH] gb: add gb-task-build-post, optimize packages with identical rebuild
Date: Sun, 14 Jun 2020 01:30:01 +0300
Message-ID: <20200614013001.902db51579d5f9714fb045dc@altlinux.org> (raw)
In-Reply-To: <20200613211049.GC24260@altlinux.org>

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

On Sun, 14 Jun 2020 00:10:49 +0300 Dmitry V. Levin wrote:
> On Sat, Jun 13, 2020 at 11:57:08PM +0300, Andrey Savchenko wrote:
> > On Sat, 13 Jun 2020 23:48:38 +0300 Dmitry V. Levin wrote:
> > > On Sat, Jun 13, 2020 at 09:50:37PM +0300, Andrey Savchenko wrote:
> > > > 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.
> > > 
> > > So what?  Failed build is not a crime, let it fail.
> > 
> > Intentionally wasted maintainer's time is a huge crime. Let a
> > machine work instead of a human, this way we can be more productive.
> 
> I suppose packages are built for a reason, so every unchanged build
> must be a mistake, and I read this as an argument to fail such builds.

Filter them out automatically if you can, keep them if you can't.
But wasting human time for such type of work is nonsense and should
not be allowed.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-13 22:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04 19:58 [devel] Optimize rebuilt subtask packages identical to the packages in the target repo Vladimir D. Seleznev
2020-06-04 19:58 ` [devel] [PATCH] gb: add gb-task-build-post, optimize packages with identical rebuild Vladimir D. Seleznev
2020-06-05 13:40   ` Alexey Tourbin
2020-06-05 14:22     ` Vladimir D. Seleznev
2020-06-06 13:42       ` Alexey Tourbin
2020-06-13 17:45         ` Dmitry V. Levin
2020-06-13 18:50           ` Andrey Savchenko
2020-06-13 20:48             ` Dmitry V. Levin
2020-06-13 20:57               ` Andrey Savchenko
2020-06-13 21:10                 ` Dmitry V. Levin
2020-06-13 22:30                   ` Andrey Savchenko [this message]
2020-06-13 19:32           ` Vladimir D. Seleznev
2020-06-13 21:03             ` Dmitry V. Levin
2020-06-13 22:03               ` Vladimir D. Seleznev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200614013001.902db51579d5f9714fb045dc@altlinux.org \
    --to=bircoph@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git